What a first automated onboarding actually looks like
A walk through one real build, from the form the client fills in to the moment their portal opens, and the two places it nearly went wrong.
The interesting part of an automated onboarding is not the happy path. It is what happens when the client answers a question wrong, or does not answer it at all.
What the client sees
One form, then nothing else until their portal is ready. They pick the things only they can decide, the branding, the domain, who else needs access, and the rest happens without them.
What runs underneath
The order matters more than the speed. Nothing that depends on a value can start before the value exists, which sounds obvious and is where most builds break.
- The account is created and the values written to it.
- Templates read from those values rather than being edited by hand.
- Domain and messaging registration start together, because they are the two slowest and neither blocks the other.
- A dummy client runs end to end while the registrations are still pending.
- The portal opens only once the dummy run has passed.
Where it nearly went wrong
Twice, and both were the same shape of mistake.
The first was a template that had a value pasted into it rather than read from the account. It worked in testing because the test account happened to be the one it was pasted from.
The second was the messaging registration, which can be rejected hours later with no notification. The fix was not a faster check. It was making the portal refuse to open until the registration came back approved, so a silent failure became a visible block.
What was worth keeping
The dummy run. It costs a few minutes and it is the only step that proves the whole chain works before a real client touches it.
