Customer identity and private Actions

Do not mix different identities#

Start each design by identifying what proof the operation needs. Browser continuity helps route a conversation back to the correct tab; it does not establish who owns an order. A team login permits workspace work according to membership; it is not a shopper's identity. An email typed in a question is still a claim from the visitor. Even trusted context sent by your backend is support context, not automatic authorisation for every private operation. Keep those categories separate in integration notes so a later developer does not accidentally use an observable account ID or greeting name as permission to return personal records.

How Action email verification works#

The customer should use the email associated with the record they want to access. Check for typing errors before requesting the code. After a resend, use the current challenge rather than guessing that any earlier message is valid. If the timer or attempt limit is reached, follow the supported fresh verification flow. The bounded grant applies to the current conversation, so a separate conversation or expired session can need verification again. Do not train staff to collect one-time codes manually: enter them only in the widget's dedicated field. The successful result proves mailbox control for this operation path, not a verified legal name.

Your provider must enforce ownership#

An identity-required HTTP read receives the verified email as verified_email in its query. A write receives customer.verifiedEmail in JSON. The provider must use that verified value to authorise the record.

For a custom order-status endpoint, first validate the operation's inputs, identify the candidate order, and compare its owner against the verified email supplied by the integration. If the relationship fails, return a safe unavailable result instead of the other person's delivery address or internal account details. An attacker knowing an order number must not gain useful confirmation about another customer's record. Apply your business rules even when the request arrived with a valid integration credential: that credential authenticates the calling service, not the shopper's right to every row. Test ownership with intentionally different customer records before enabling the Action.

Identity is separate from confirmation#

Write execution requires the customer's Confirm & submit, permitted current access and a valid proposal for the current tested Action revision. A pending proposal expires after ten minutes.

Review confirmation as a separate checkpoint. The card should display exactly the relevant inputs the customer is approving, such as the order reference and requested change. If they cancel, do not execute the operation behind a friendly conversational reply. If staff edit the Action after the proposal is created, its old card may no longer be valid; produce a current proposal through the supported flow instead of forcing it to run. A verified email does not imply blanket approval for a refund, booking or account edit. Likewise, a successful write result does not imply that unrelated follow-up operations were performed.

Handoff contact does not verify an account#

A visitor can provide a misspelled or someone else's email in a handoff form. The form collects a route for follow-up and the visitor's confirmation to share the exchange; it does not challenge the mailbox. Staff receiving the summary should use their normal procedure before changing an address, discussing a private account or approving money movement. The configured response expectation should describe actual service, not turn submitted contact details into proof that a human replied. If verification mail for an Action fails, the alternative is a legitimate business support path with appropriate checks, not a bypass that silently marks the visitor verified.

Locate the failure before changing the identity flow#

An identity problem can occur before mail is sent, while mail is delivered, during code validation or after verification at the provider. Note which stage failed. If the form rejects a request immediately, capture the safe message and whether the resend wait applies. If the request succeeds but mail is absent, check the entered address, spam and mailbox rules. If mail arrives but the code is rejected, check that it belongs to the current conversation and latest challenge and is still within its lifetime. Do not repeatedly request codes while simultaneously trying older messages.

If the verified state is established but the lookup remains unavailable, investigate record ownership and provider access rather than the mailbox challenge. The two events prove different things. An administrator should reproduce the boundary with a controlled record, documenting expected owner and result. The browser must not force a verified state, and staff should not ask the customer to send one-time codes through ordinary support chat. A normal business contact fallback can resolve a legitimate issue through that business's authorised procedure. Keep the challenge timers and provider decision in the report so support can identify the smallest failing step.

Specify the provider decision as a narrow contract#

Write an endpoint contract that names the requested record, the verified customer attribute and the allowed result. For example, an order-status read accepts an order reference, checks its owner against the verified email and returns only a safe status and delivery estimate. The same integration credential may be able to reach many records, so it must never be used as a substitute for the per-customer check. Avoid a design that first returns a raw record and expects the assistant to decide which private fields to conceal.

Define an unavailable response for a missing or unowned record without revealing another person's name, address or internal status. Then test four relationships: the correct record and owner, another owner's reference, a nonexistent reference and an expired verification grant. Keep those tests independent of the business's wider identity requirements. Mailbox control alone may be insufficient for some sensitive action; implement the necessary business checks in the responsible system before enabling that operation. If your integration changes from read to write, revisit the contract and explicit confirmation, rather than treating a previously successful lookup test as approval for a new class of change.

Explain identity limits to support staff#

Staff receiving a handoff should know whether its contact details were merely entered in the form or an Action used a verified mailbox. A familiar name, saved conversation, browser visitor ID or confident assistant reply is not additional evidence of customer ownership. Include the safe case reference and the required business verification procedure in the staff workflow. If an email address was mistyped, collect the correct contact information through that procedure instead of using the original form as an account-update authorisation.

A useful training scenario asks staff to handle a legitimate person who cannot receive verification mail and an unrelated person who knows an order number. The first needs a usable support path; the second must not gain private records by bypassing the challenge. Decide who can approve a sensitive change outside the automated path and where that approval is recorded. Reesponder's Action result should describe only the operation it actually performed. A staff member later approving a refund is a separate business decision, with separate evidence, and should not be retrospectively attributed to mailbox verification or an earlier contact submission.

Test ownership with two synthetic customers#

Build a test using two synthetic customers, Alice and Ben, with different order references and addresses. Verify Alice's mailbox and request Alice's permitted order: the narrow authorised fields should be returned. In the same controlled integration, ask for Ben's order using Alice's verified identity: the result should be unavailable without exposing Ben's details. Then test an expired grant and a cancelled write proposal. These cases reveal whether the provider implements ownership and whether confirmation really gates execution. Use non-production records or a safe test endpoint; a write test can change the connected system and is not merely a visual preview.

Verify the outcome and keep safe evidence#

Record the verification timing, Action revision, safe run reference and expected provider ownership result. Inspect the customer-visible card as well as the backend response, since an overly broad mapping can expose information even when a lookup succeeded correctly. Test resend timing, invalid and expired codes through the normal interface without sharing codes in a ticket. Review what happens when the endpoint is unavailable or a write returns unknown; support should investigate the existing run rather than recommend blind repetition. Document the business checks beyond mailbox control if the operation requires them, and keep those checks in the system that owns the records.