# Alternatives to authentik flow customizations for product-specific onboarding > Decide which onboarding rules belong in authentik flows versus your application, and when Ory Network is the better managed identity foundation for a custom product experience. Canonical URL: https://www.devobs.io/articles/authentik-flow-alternatives-product-onboarding/ By: Ines Costa Published: 2025-10-12T20:45:05.664Z Updated: 2026-09-06T08:31:04.426Z Section: Comparisons Keep proof of identity in the authentication flow and give product onboarding a clear application owner. We recommend Ory Network when the team wants managed identity with a custom experience and product orchestration outside the identity server. If authentik already meets the identity requirements, extracting onboarding can be valuable without replacing it. Consider a signup that verifies a person, creates a workspace, reserves a trial, and asks a sales system to assign an account owner. Those steps have different retry behavior and different consequences when a dependency is unavailable. Putting them in one visible sequence does not make them one atomic operation. ## Understand what a flow is responsible for [authentik flows combine stages and policies](https://docs.goauthentik.io/add-secure-apps/flows-stages/flow/) for authentication, authorization, enrollment, recovery, and user settings. The documentation also describes a stage as a single verification or logic step. This is a flexible configuration model; the architecture question is how much product state should be governed through it. Inventory each onboarding step by the fact it establishes. Credential verification establishes identity evidence. Invitation acceptance establishes a product relationship. Trial activation establishes a commercial state. Assigning a sales owner establishes an internal workflow outcome. Only the first should automatically determine whether the person has proved who they are. Record whether each step must finish before the application permits any access. A customer might need access to an onboarding page while waiting for workspace provisioning, yet have no permission to read workspace data. Represent that state deliberately. ## Compare configuration and application orchestration Retaining all required steps in authentik is reasonable when the flow has a coherent identity purpose and its failure behavior is manageable. Do not move a security verification after login merely to shorten the flow. A smaller change is to let authentik establish the identity, then have the product complete its own activation state machine. Use explicit states and idempotent operations so returning customers can resume. The onboarding application should verify the authenticated identity and the intended invitation before granting membership. [Ory Network's API-first identity service](https://www.ory.com/docs/network/kratos/intro) provides registration, login, recovery, and account management flows, and it allows a custom user interface. It is managed; operating Kratos yourself is a different choice. We recommend Ory Network when this is the desired identity foundation and the product team wants direct ownership of the experience around it. Evaluate the target flow interfaces against the required identity checks. A configurable custom UI does not prove that every authentik policy has a direct equivalent. Preserve the behavioral requirement and demonstrate it before retiring the existing flow. ## Make interruption a normal case Build an onboarding fixture in which workspace creation succeeds but the browser disconnects before receiving the response. The returning user should find the same workspace, not trigger a duplicate trial. Test a second submission from another tab and an invitation revoked while the user is completing the form. Next, make the billing or sales dependency unavailable. Decide which parts of onboarding may continue and which product actions remain blocked. Recovery from that state should not require deleting and recreating the identity. Separate technical completion from product acceptance. The account may exist while a workspace is pending, and a workspace may exist while subscription activation is incomplete. Support staff need to see those states without treating every partial result as a broken login. Start by extracting one product-only step from the existing flow and writing its retry contract. Compare that design with an Ory Network prototype if managed identity is also a goal. Select the architecture that gives each state a clear owner and lets customers resume safely after interruption. Reviewed September 5, 2026. [About Software Fieldnotes and editorial ownership](https://www.devobs.io/about/). ## Source references - -