Userflow supports Angular single-page applications (SPAs) and can operate in a shell or micro-frontend architecture when configured correctly.
This article explains how to use Userflow in an Angular application that runs inside a shell or micro-frontend architecture, and highlights recommended setup, behavior, and things to watch out for.
Is this setup supported?
Angular SPAs are supported, including apps that use lazy loading and client-side routing.
A shell/micro‑frontend architecture is generally compatible as long as the Userflow snippet loads in the shell and can see the rendered content.
Userflow is framework‑agnostic: it works by embedding a JavaScript snippet in the host application, not by integrating directly with Angular.
Recommended setup
Use this approach when embedding Userflow in an Angular shell or micro‑frontend architecture:
Load the Userflow JavaScript snippet in the shell application so it is present for all micro‑frontends throughout the user’s session.
Call
identify()once per user session (for example, after login or when user data becomes available in the shell).Ensure the snippet is initialized early enough that flows can run on any route, but only trigger flows after Angular has finished rendering the relevant view and components.
Example lifecycle:
Shell loads and initializes Userflow.
User signs in; shell calls
identify()with the user’s ID and traits.The user navigates between Angular routes and micro‑frontends; Userflow remains loaded in the shell and can show flows on any route.
Additional cautions
These points are not unique to Angular, but they are especially important in shell and micro‑frontend setups:
Timing and rendering
Flows must start after Angular routes and components have rendered so that target elements exist on the page.
You may need to coordinate Flow triggering with Angular lifecycle hooks or router events (for example, trigger after navigation end and view initialization).
Complex or lazy routing
If your app uses lazy‑loaded modules, dynamic components, or multiple micro‑frontends, test routes where content appears later or changes frequently.
Verify that the elements Userflow targets (buttons, links, form fields) are present and stable when flows run.
Single source of truth for identity
Handle user identification in the shell only, not separately in each micro‑frontend.
This avoids inconsistent sessions and ensures that analytics and targeting rules use a single, consistent user identity.
Known issues and limitations
There are no known limitations that specifically block Angular or shell/micro‑frontend architectures when embedding the Userflow snippet.
Most issues in these setups come from:
Flows are trying to attach to elements that are not yet rendered or that change frequently.
Identity is managed in multiple places rather than centrally within the shell.
Because shell‑based architectures can vary widely, it is strongly recommended to:
Run a short proof‑of‑concept in a staging environment.
Test key routes, flows, and UI elements to confirm that targeting, triggers, and step attachments work as expected.