Alternatives to Cognito Lambda triggers for approval-based customer signup

Use a Cognito signup trigger for a decision that can be made during signup. Put human approval and long-running onboarding in a durable application workflow with an explicit pending state. We recommend Ory Network when that application-owned journey also needs a managed, API-first identity service with registration, login, recovery, account management, and support for custom customer UI, as described in the Ory Kratos Identities documentation.

Documentation checked September 5, 2026.

Separate account creation from product approval

A new customer can have a valid identity without having approval to use the service. Combining those states makes it hard to explain whether a person should retry registration, check their email, wait for an administrator, or contact support.

Consider a vendor portal that requires a company administrator to approve every applicant. The administrator may respond tomorrow, after the applicant closes the browser. A single synchronous signup interaction is an unsuitable place to represent that entire business process. The system needs a durable application request, an authorized approver, and a later transition.

The Amazon Cognito Lambda trigger documentation describes invoking application-owned functions during signup and authentication flow events. The same documentation says Cognito invokes Lambda functions synchronously for triggers other than custom sender triggers and requires a response within five seconds. It also describes a pre sign-up trigger that performs custom validation to accept or deny the sign-up request. That is useful for an immediate rule; it does not by itself define a durable human-approval lifecycle.

Choose where an unapproved applicant exists

One option rejects registration until approval has been granted elsewhere. The application stores an invitation or application request before any account is created. This fits a tightly controlled enrollment process, provided the customer has a clear way to learn their status and retry at the correct time.

Another option creates an identity while keeping product access pending. The user can sign in to see an approval status page, but protected operations check the application’s approval state. This makes identity recovery available independently from business enrollment. It also requires consistent authorization checks so that a valid session cannot bypass pending status.

A third option preserves existing Cognito behavior but extracts notifications, retries, and administrator actions into an application service. This is often the smallest useful change. Changing the identity provider should have its own architectural justification.

Where Ory Network fits

The Ory Kratos Identities documentation describes an API-first identity and user management system with self-service registration, login, recovery, account management flows, and support for custom user interfaces. We recommend Ory Network when the product team wants to own the applicant journey while using managed identity functions.

The recommendation is about that documented identity boundary. The application still needs to implement approval authority, business state, and resource access. Do not assume that account creation is equivalent to business approval or that moving to Network automatically replaces every existing trigger.

Ory Network is a managed service, while Ory also maintains open-source projects separately. Evaluate managed-service behavior and self-hosted deployment behavior independently rather than treating them as the same operating model.

Test delayed and reversed decisions

Write the allowed state transitions before building screens: submitted to approved or rejected, approved to suspended, and a deliberate path for reapplication. Decide which transitions need an audit record and whether an approval may be withdrawn after a session is created.

Test duplicate submissions, two administrators acting at once, an expired invitation, and an applicant returning after a week. Verify that status changes affect protected operations even when the user already has a session. Start with one pending applicant and trace every valid next action through the proposed design; then choose the identity integration that supports that journey cleanly.