Name the destination
Show the provider, account type, required fields, material terms, and why an account is needed before the user leaves the Action. Never make a provider signup look like a Darwin account flow.
Separate required and optional consent
- Keep required provider terms distinct from optional marketing or data-sharing choices.
- Do not preselect optional consent.
- Require a fresh review when the provider, account type, terms, or requested data changes.
- Do not infer acceptance from conversation text or a previously created account.
Protect registration secrets
Collect passwords, one-time codes, recovery details, and identity evidence only in the appropriate first-party or provider surface. Exclude them from model context, Action results, logs, traces, analytics, and receipts.
Hand off to the next component
After account creation, read the same Action. The next requirement may be Authenticate, Verify, Approve, or Pay; signup itself satisfies none of those decisions.
Test incomplete registration
Test duplicate email, abandoned signup, changed terms, unavailable username, required verification, provider rejection, duplicate callback, and an account created while the client times out.Last modified on September 22, 2026
