User journey map

Personas

Who comes in, and how: an admin invites each person by email, with a role and, for a member, permissions per project. The owner's break-glass account needs no invitation.

The app developer's journey

Wiring FlowDeck to the console. A database migration makes FlowDeck's project, its queues (email, push, ai, timer), its service account and its jobs, so the developer adds only a key and four settings.

Phase	What they do	Screen	What the console shows	Feeling or concern
Discovery and invitation	An admin invites them, as a member with the keys permission in the project, or as an admin. They open the mailed link within 7 days.	The invitation page, /inviteNo screenshot; see Signing in	The mail: You are invited to Cloud Console. The page: Sign in with the Google account the invitation was sent to. Another account is turned away, and the invitation stays open for the right one. Then Accept with Google.	Curious, a little wary: which Google account was it sent to?
Onboarding and first sign-in	Accept with Google, with the invited address. The first page is the dashboard.	Dashboard	Another Google account: This invitation is for another address: sign in with the Google account it was sent to. An old link: This invitation has expired or was used; ask an admin to send it again. In: No failures in the last 24 hours.	Relieved to be in; not yet sure where the keys live.
Setup	Choose the project, open API keys and create a key. Put it in the app's settings with the console's URL, the project's name and the service account (for FlowDeck: CONSOLE_URL, CONSOLE_PROJECT, CONSOLE_API_KEY, CONSOLE_SERVICE_ACCOUNT). Check the key with GET /v1/projects/{p}.	API keys	The key, once: Copy it now and keep it in the app's settings. You won't see it again: the console keeps only a hash of it. Without the permission: Managing API keys needs the keys permission in this project. Ask an admin. The check answers the project's name.	Careful: the key shows once, so it goes straight into the app's settings.
Doing the task	The app sends POST /v1/projects/{p}/queues/{q}/tasks with the key: a URL, a body, and OIDC auth as the project's service account. They watch the queue's Tasks tab, then a task's page.	A queueThen a task	201 with the task, in state Queued until its time, then Succeeded once the target answers 2xx. The target checks the token: its signature, iss, aud, exp, and sub or email against the service account.	Confident once the first task shows Succeeded.
Something goes wrong	The console refuses a request, or the target refuses the call.	A task	A name sent again: 409 A task named order-1001 is in this queue, or succeeded or was deleted within the last day. An expired key: 401 This API key has expired. The cap: 429 The project's daily quota of 5000 tasks and job runs is used up. A target that answers 404: the task fails at once, 404 Not Found; stopped: 404 is not retried.	Worried at first: is it the app or the console? The message says which.
Done	Let the work run. Before a key's end, rotate it on API keys and move the app to the new one.	API keys	A warning 7 days and 1 day before the end: API key expiring in shop: shop-app. Rotate: Rotating shop-app: the new key is made now; the old one keeps working until the end below, or until you revoke it. Left empty, the old key ends in 7 days.	Calm: the work runs without them, and the console warns before a key ends.

The operations admin's journey

Running the queues and jobs of several projects, within one free Cloudflare account.

Phase	What they do	Screen	What the console shows	Feeling or concern
Discovery and invitation	The owner invites them as an admin from People (or makes a member an admin). They open the mailed link.	People	The mail: To accept, open this link within 7 days and sign in with Google as the invited address. To the owner, for an address already in: That person is here already; for one invited twice: That address is invited already; resend the invitation instead.	Ready to take over the day-to-day running.
Onboarding and first sign-in	Sign in with Google. The dashboard comes first.	Dashboard	The failures: 3 failed job runs and 12 failed task attempts in the last 24 hours, or No failures in the last 24 hours. Each free-plan line with its level, and the cron: Last run noted 3 minutes ago. Then Failing jobs, Backlogs, Slowest jobs and the success rates.	Wants the whole picture at a glance.
Setup	Create a queue with its rate, retries and priority; create a job in three steps; set the project's alerts; set a project's daily cap on Usage.	Create a jobAlso Create a queue, Alerts	Each refused field's message beside it, such as minBackoff is at most maxBackoff. The next five run times under the schedule, in the job's time zone. The cap's hint: Empty for the default (5,000); 0 for no cap.	Careful with every number that costs the free plan.
Doing the task	Watch the queues' metrics and the jobs list; force run, pause and resume jobs; turn on the daily summary.	JobsAlso a queue's metrics	A job's state: Enabled or Paused. Its last run: Success, Failed (503), Skipped (daily quota) or Has not run yet.	In control, as long as the numbers stay green.
Something goes wrong	An alert comes: a job failing twice in a row, or the console near a free-plan limit. They open Usage.	Usage	At a limit: A free-plan limit is used up: every queue is held, and new tasks and job runs are refused, until the next UTC day. To the apps, 429: The console is over a free-plan limit today; new tasks are refused until 2026-10-23T00:00 UTC. A stopped cron, on the dashboard: Last run noted 25 minutes ago: the cron may have stopped.	Under pressure: which project, and how long until it clears?
Done	Raise a project's cap if it needs more. Once the target is back, retry the queue's failed tasks.	A queue, Failed tab	Retried failed tasks: 3. One alert when the failing job recovers. The hold ends with the UTC day.	Relieved; tomorrow's summary will show the recovery.

The read-only member's journey

Checking on failures in one project, with the Viewer preset: read and nothing else.

Phase	What they do	Screen	What the console shows	Feeling or concern
Discovery and invitation	An admin invites them with the Viewer preset on one project. They open the mailed link.	The invitation page, /inviteNo screenshot; see Signing in	The mail: You are invited to Cloud Console. Accept with Google, with the account the invitation was sent to.	Hopes it is quick: they only need to look.
Onboarding and first sign-in	Accept with Google and land on the dashboard.	Dashboard	Only the projects they may read. No API keys, Alerts, People or Audit log in the navigation: each needs a permission they do not have. Another project's address: 404 No such project.	Reassured: a small view, and nothing to break.
Setup	On Your account, turn on the daily summary in their time zone; add a passkey for quicker sign-in.	Your account	On: each morning at 08:00 (Asia/Kolkata). A passkey added too long after signing in: Sign in again to add or remove a passkey.	Glad not to check by hand each morning.
Doing the task	Follow a failing job or a failed task from the dashboard: the job's Logs, or the queue's Failed tab, then the task's page.	A taskAlso a job	Failed and the task's last error. Each attempt: its time, duration, status or error kind, content type and the first 1 KB of the answer. Nothing failed: No failed tasks. Failed tasks are kept for 7 days.	Focused: wants the cause, in words.
Something goes wrong	They want the task retried, but have no button for it. They filter a long task list again and again.	A queue	No Run now, Retry or Delete: only the actions the API lists. A call they may not make answers 403 You do not have the run permission in shop. Past the filter limit: 429 At most 10 filtered or sorted task lists an hour; try again later. In a big queue: Showing matches among the newest 500 tasks.	A little stuck, but clear about what to hand over.
Done	Send the task's name and error to someone with the run permission, who retries it.	A task	The retried task keeps its name and logs, starts again from 0 attempts, and shows Succeeded once the target answers 2xx. The next morning's summary counts the day's failures.	Done in minutes, without changing anything themselves.

The owner's journey, as the break-glass admin

Getting in without Google: on the first day, and on any day Google sign-in is not available.

Phase	What they do	Screen	What the console shows	Feeling or concern
Discovery	Deploy the console with ADMIN_EMAIL set. There is no invitation: the console makes the account at the first sign-in or forgot-password attempt.	Sign in	Google not set up: Sign in with Google is not set up on this console. The break-glass admin can still sign in. The link: Sign in as the break-glass admin.	Needs a way in before anything else works.
Onboarding and first sign-in	Choose Forgot password?, send the link to ADMIN_EMAIL, open it within 30 minutes and set a password of 16 characters or more. Sign in with the code left empty, enrol an authenticator, and keep the backup codes.	Admin sign-in	If that is the break-glass admin's address, a link to set a new password is on its way. It works once and expires soon. A short password: The new password must be at least 16 characters. Enrolment: Scan with your authenticator app, then Enter the 6-digit code from the app., then ten backup codes, shown once.	Methodical: the backup codes must go somewhere safe.
Setup	Invite the others from People. Add a passkey to the account, as a second way in.	PeopleAlso Your account	With mail off: Mail is off: set the MAIL_* settings to send invitations. The break-glass row signs in with Password and code (break-glass), and offers no Demote, Disable or Remove.	Building the team, and a spare way in.
Doing the task	On a day Google is not available, sign in with the email, the password and the code from the authenticator, or a backup code.	Admin sign-in	The one local account, for when Google sign-in is not available. The code's hint: From your authenticator app, or a backup code. Leave it empty the first time. Each such sign-in is mailed to the admins as a security alert.	Uses it rarely, and needs it to just work.
Something goes wrong	They type a wrong code, or someone else keeps trying the account.	Admin sign-in	Any wrong try, and a locked account alike: Wrong email, password or code. Too many tries from one address: Too many sign-in attempts from this address; try again later. At enrolment: Wrong code: enter the code your authenticator shows now, or The enrolment has expired; sign in again.	Anxious: shut out of their own console. During a lock, a second admin with Google, or the passkey, gets in.
Done	Get in another way, and read the audit log for the lock and the tries.	Audit log	Audit lines such as auth.locked and auth.sign_in, each with who, what and when. After a reset: Your Cloud Console password was changed, every session signed out.	Back in control, with a record of what happened.

Moments that matter

Where the console has to be clearest, and what it shows there.

The other documents: UI and screen flow, annotated screens, the clickable prototype, the style guide and the user manual.

Built from Cloud Console's main branch (CAP-162), 22 Oct 2026. Example values only: no real keys, emails or ids.