Skip to main content
User Types defines who uses your app and what each persona does. It’s the source of truth for permissions, feature access, and the role-based parts of the generated UI.

​
What you configure

Each user type has:
  • A name (e.g. Admin, Customer, Vendor, Guest)
  • A description explaining who this persona is and what they need from the app
  • A list of use cases — the actions or workflows this persona performs
Use cases are the bridge between user types and features. When Archie generates code, every feature gets routed to the right user types based on the use cases attached to each persona.

​
How user types feed code generation

User types influence:
  • Authentication and authorization — which login flows, MFA requirements, and role assignments end up in the code
  • Role-based access control — which routes, features, and data each persona can reach
  • Conditional UI — what each persona sees on shared screens (e.g. an Admin sees “Delete user” on the user list; a Customer doesn’t)
  • Onboarding flows — different welcome experiences per persona
Add and remove user types as your understanding sharpens. Archie’s agents read the full set when generating code.

​
FAQ

Group together personas who do roughly the same thing. “Admin” and “Super Admin” are usually one user type with a permission flag rather than two separate types. Treat them as separate types only when their workflows diverge enough to need different navigation, different default screens, or different feature sets.
A user type is a persona — Admin, Customer, Vendor. A use case is something that persona does — “Approve a refund”, “Place an order”, “List a product”. Each use case attaches to one or more user types and informs which features that user type can access.
Yes. Add a “Guest” user type for visitors who don’t have an account. Use cases for Guest typically include browsing public content, signing up, and logging in. Archie generates the unauthenticated routes accordingly.
Archie supports as many user types as you need, but consider whether they really need separate types or whether they’re variations of a smaller set with different permission flags. Maintenance is much simpler with fewer types.