The request that arrives every quarter
A large client asks for its own registration flow. A business line needs three extra fields at onboarding, and only for its own customers. A partner wants the authentication screens in its own brand, with its own consent wording.
None of these requests is unreasonable, and none of them is about identity in the abstract: they are about what the user sees. Which is why they land on the application team, and why they are expensive.
What one customisation used to cost
The application owns the interface, so customising the interface means changing the application. From there the options are all bad in a different way:
- A fork per client. The codebase splits, and every fix has to be applied several times, in several places, by somebody who remembers all of them.
- Conditional logic inside the monolith. The single codebase survives, but fills with branches tied to tenant identity. After a few dozen clients nobody can say with confidence what a given tenant will see, and every deployment becomes a risk exercise.
- A release cycle for a form. Weeks of building and testing a client-specific interface — planning, development, QA, deployment — for what is, in substance, a different set of fields and a logo.
The compounding cost is not the first customisation. It is the twentieth, arriving while the previous nineteen still have to be maintained.
Moving the interface out of the application
The alternative is to stop treating the interface as part of the application and start treating it as the last step of an identity journey — which is where the context lives anyway, because the system already knows who is signing in and on whose behalf.
With the Visual Identity Orchestrator and a component library that carries no client-specific code, the flow is assembled at the moment of access:
- The context is recognised. At sign-in the journey establishes the affiliation: a business partner, an end customer, an employee of a specific branch.
- The journey is assembled. The orchestrator applies the rules attached to that tenant or role — which steps are required, which attributes have to be collected, which disclosures have to be shown.
- The frontend is rendered on demand. Modular widgets and forms generated at runtime display exactly those fields, that brand and those steps, with no ad-hoc code inside the application.
Adding the twentieth client is then a matter of configuring nodes on the canvas, not of opening the application’s source.
What stays in the application
Orchestration takes the sequence, the fields and the presentation of the identity journey. It does not take the product: business logic, domain screens and everything that happens after the person is in stay exactly where they are.
That boundary is what makes the approach hold. The application stops carrying tenant branches because it no longer needs to know which client is in front of it — the journey does, and it hands over an identity that is already established, together with the attributes it was asked to collect.
What changes
- One codebase, no forks. Interface components stay composable and client-agnostic; what differs between clients lives in the journey, not in the code.
- A new requirement is a configuration, not a release. A different flow for a single client is drawn and published, without waiting for a development cycle.
- Deployments get boring again. Removing tenant conditionals from the application removes the reason most deployments were treated as risky.
For estates where each client is effectively its own tenant, this pairs with multi-domain: separate populations, separate branding and separate administration, on one platform and one codebase.