AA. Active choice (recommended)
- Required, with nothing pre-selected. Next without an answer says “Please choose an answer”.
- Her answer is logged as her own event with the IP; a No is logged too. A Yes sends her the confirmation email.
What changed from E2, mapped to the call
- 1
Dealer booking is an account setting, on or off. It never belongs to an admin. It shows as its own block near Authorised users, never as a row or a pill on an admin’s row. E2 had one dealer authorisation per relationship manager.
- 2
Three ways on, four ways off, every change logged. On: by her at registration or in Settings, or by an admin with evidence (a new security procedure, approved on submit). Off: by her in Settings, on the review or from the email link, or by an admin with a reason.
- 3
Any admin who can see her adds themselves. One click, fixed permissions, no approval and no email to her. The admin who turns it on with evidence gets theirs in the same step.
- 4
Off stops every dealer booking user. Live sessions included; turning it back on restores them. Users she approved through the old flow are untouched.
- 5
No relationship-manager or leaver logic. An admin leaving only stops that admin. E2’s RM-change tour and its Suspended state are gone.
- 6
No step per booking. E2’s instruction form and “one instruction covers one booking” are dropped. Log in as authorised user starts from her admin page only; no account picker lists it.
- 7
A new evidence form. How she asked; a link and/or an upload; asked from a contact on file; an optional description; one block for what she’ll read; the summary left-aligned.
- 8
Her side is one place. The email and the notification both open Settings › Authorised Users. The promise drops “can’t change your details” for “New recipients need your approval”.
Registration
The real Transfer Requirements step, web and phone. One question, three variants.
BB. Default on
- “Yes, when I ask” is pre-selected: one tap to change.
- Weaker evidence if a client ever disputes it.
CC. Opt in
- A switch that’s off, marked optional. Fewest clients turn it on.
+The wording
“Can our dealers book transfers for you?” with “Yes, when I ask” (By phone, WhatsApp or email. New recipients still need your approval.) or “No, I’ll book online myself”, as agreed.
An alternative, not a replacement: “Can our dealers book transfers for you when you ask?”, so the answers can be a plain “Yes” and “No, I’ll book online myself”.
Desktop: A. Active choice (recommended)
- Required, with nothing pre-selected. Next without an answer says “Please choose an answer”.
- Her answer is logged as her own event with the IP; a No is logged too. A Yes sends her the confirmation email.
Settings › Authorised Users
Her one place for dealer booking: the block sits above the list. The email and the notification both lead here.
Please check
- After an admin turns it on with evidence. Keep it on and Turn it off are the same size.
- Either answer is logged and clears the notification. There’s no separate approval page.
Every state, on a phone
1Off
- She answered No at sign-up. Turn on opens the promise first.
2Turning it on: the promise first
- The three promise lines, then Turn it on. Logged with her IP, and she gets the confirmation email.
3On
- She said Yes at sign-up. Daniel added himself: he’s in her list as CurrencyTransfer staff, with plain-words permissions.
4Please check
- After an admin turns it on with evidence. Keep it on and Turn it off are the same size.
- Either answer is logged and clears the notification. There’s no separate approval page.
5After Keep it on
- Says who turned it on, after which conversation, and when she kept it.
6After Turn it off
- Dealer booking users stop at once and move to Suspended. Ruth, the colleague she added herself, stays active.
7One staff authorised user
- Today’s page with the CurrencyTransfer staff label: she can change permissions (Save User) or Suspend User, as today.
- Fixed permissions to start: book trades Admin, allocate payments Admin, manage recipients Submitter.
8The Suspended tab while it’s off
“Off while dealer booking is off”: they work again when she turns it back on.
The email, the turn-off page, the notification
Sent when an admin turns it on with evidence, and as a confirmation when she turns it on herself.
Email: “We’ve turned on dealer booking for you”
- First line by channel: “Thank you for your call / WhatsApp message / email.”
- Review dealer booking opens Settings; Turn it off opens the no-login page.
Email: “You’ve turned on dealer booking” (confirmation)
- Sent whenever she turns it on herself: the Yes at registration, Turn it on in Settings, and Turn it back on. The same layout as the email above.
- First line by source: “…for your account when you signed up” (shown) or “…in Settings” (open the Settings one). Logged in the consent history as “Email sent”. Turning it off herself sends no email.
Email: an admin turned it off
- JIRA section 8: we email her when an admin turns it off. The internal reason isn’t in the email.
The tray (desktop)
- “Dealer booking is on”, in the action style, until she answers. The same item is under Recent activity.
The turn-off page, no login
1Turn-off page: confirm
- No login. Opening the link changes nothing; the button is a POST, because mail scanners open links.
2Turn-off page: done
- Says when. Every dealer booking authorised user has stopped, live sessions included.
3Turn-off page: an earlier link
- Already off: the page says when and how, and changes nothing.
Desktop: the turn-off page
- No login. Opening the link changes nothing; the button is a POST, because mail scanners open links.
On a phone, the bell is in the menu
1The drawer (phone)
- On a phone the bell is in the app’s menu: Notifications, with the count.
2The tray (phone)
- Tapping Notifications opens the list; the item opens Settings.
+Recent activity
The same item sits under Recent activity on the dashboard, with View details. It stays until she answers.
The session bar (nice to have)
- “Acting for Margaret Ellwood as Daniel Mercer · End session”. Nice to have, if cheap (JIRA section 6).
- Admins reach her account only from her admin page: no account picker lists their authorised users.
Admin portal
Her Authorised Users page, rebuilt on the real page with the client record’s own tabs: Authorised users | Consent history.
Off: Turn on with evidence, or request access
- The block shows Off and nothing more. With no evidence, the existing request flow is the way in.
Just turned on with evidence
- Since when, by whom and how, in the admin’s own badge. His authorised user was created in the same step.
On: Add me as authorised user
- For any admin who can see her and has no row. One click: active at once, no approval, no email.
- Associate directors and partnership managers only see their own clients, as today; there’s no team logic.
On: your own row, Log in as authorised user
- Admins’ rows say CurrencyTransfer staff and their source. The log-in action sits on your own active row.
Turn off, with a reason
- Reason required. Every dealer booking authorised user stops; old-flow ones keep working. We email her.
After she turned it off
- Daniel’s and Aisha’s rows: ✗ “Off while dealer booking is off”. Ruth, approved by her, still ✓.
Daniel left; Aisha added herself
- Leaving only stops that admin. No suspend-on-leave and no relationship-manager logic.
Old flow: request pending
- Today’s text for a pending request; the row waits for her approval.
- If dealer booking is turned on, from any source (her Yes at registration, Settings, Turn it back on, or an admin’s evidence), this request is activated at once with the dealer booking permissions and source, with no further approval. Logged as “Pending request activated: Daniel Mercer (dealer booking turned on)”. Tour 5 shows it.
Old flow: approved by the client
- Source: approved by the client. Turning dealer booking off doesn’t touch it.
Consent history tab
- Append-only, newest first: when, event, who, where, evidence, IP, reason. Plain columns.
The evidence form
Evidence form: recorded call
- How she asked; evidence (a link and/or a file); asked from a contact on file; optional description.
- One block for what she’ll read; the summary below it is left-aligned.
Evidence form: WhatsApp, with an upload
- WhatsApp and email have no message links: the evidence is an upload. JPG, PNG, PDF or email files (.eml), up to 50 MB each, one or more files; evidence is kept indefinitely. For email, the sample upload is the .eml itself (open the email version).
- “Automatic check of screenshots: later.”
Evidence form: nothing filled in
- The button is disabled and says what’s missing: how she asked, a link or a file, and the contact.
Evidence form: link warning
- A link that isn’t Aircall, WhatsApp or email gets a warning, not a block.
Request authorised user access (the no-evidence path)
- The real form, unchanged: he picks permissions, she approves in her app (today’s email, tray item and page).
Client record: status in the strip
- Included (decided 9 Oct): On (since when) or Off, linking to her Authorised Users. The way in stays Account › Authorised Users too.
Screen inventory, for the front-end ticket
| Screen | Platform | States | API it needs (JIRA-BACKEND section 10) |
|---|---|---|---|
| Registration: Transfer Requirements question | Web, mobile | Unanswered; Yes; No. Variants: active choice (recommended), default on, opt in | Accept the choice on the transfer requirements step (Api::V1::Onboarding::AccountsController#update), logged as registration with the IP |
| Settings › Authorised Users: dealer booking block | Web, mobile | Off; turning on (promise); On; Please check; after Keep it on; after she turned it off; off by an admin | Read: GET /api/v1/dealer_booking (or the account or settings response): on or off, since when, how or by whom. Update: PUT /api/v1/dealer_booking { enabled }, account owner only, logs settings and the IP. Keep it on logs a confirmation and clears the notification |
| Settings › Authorised Users: the list | Web, mobile | Staff row (dealer booking or approved by her); paused while dealer booking is off; suspended by her; admin left | Api::V1::AuthorizedTradersController flags staff authorised users and their source, so the apps can label them |
| One authorised user (edit page) | Web, mobile | Staff via dealer booking; staff approved by her; pending request (Activate User / Approve); suspended | Existing authorised trader endpoints, plus the staff flag and source |
| In-app notification: tray, Recent activity, phone drawer | Web, mobile | “Dealer booking is on”, until she answers; today’s “Pending authorised user” for the old flow | A new recent-activity type (or AuthorizedTraderRequest extended), cleared by Keep it on or Turn it off |
| Email: dealer booking is on | Email (web and phone) | First line by channel: call, WhatsApp message, email | Mailer in the backend ticket; Review link into the app; Turn it off link with a signed token |
| Email: you’ve turned on dealer booking (confirmation) | Email (web and phone) | First line by source: “when you signed up” (registration) or “in Settings” (Turn it on, Turn it back on) | Mailer in the backend ticket, sent on her own turn-on (registration or settings); Review link into the app; Turn it off link with a signed token |
| Email: dealer booking is off (an admin turned it off) | One state | Mailer in the backend ticket | |
| Turn-off page, no login | Web (any browser) | Confirm; done; already off (an earlier link) | Token endpoints for the one-click turn-off: the page on GET, the change on POST |
| Session bar (nice to have) | Web, client app | Acting for her as an admin; End session | End-session endpoint that restores the admin’s session (backend, if cheap) |
| Admin: Authorised Users, two tabs, dealer booking block | Admin | Off; on (with or without your row); turn off with a reason; rows: active, off while dealer booking is off, left, pending | Server-rendered (backend ticket, section 9) |
| Admin: evidence form | Admin | Empty; call with link; WhatsApp with a screenshot, or email with the email file (.eml); link warning. Uploads: JPG, PNG, PDF or .eml, up to 50 MB each, kept indefinitely | Server-rendered: the enable_dealer_booking security procedure (backend ticket, section 4) |
| Admin: Request authorised user access | Admin | Unchanged | Existing |
| Admin: Consent history tab | Admin | Newest first, append-only | Server-rendered (backend ticket, section 7) |
| Admin: client record strip | Admin | Included (decided 9 Oct). On (since when); Off | Server-rendered |