Login & access workflows
Every customer user starts at https://www.rebelcore.ai/login. After the email and password are accepted, RebelCore resolves the destination from the user’s account type and current role permissions. The destination determines the second-factor flow and the application that opens.
Account flows at a glance
| Account or role | Default landing | Second factor | Effective access |
|---|---|---|---|
| Customer Super Admin | Customer portal | Authenticator code (TOTP) | Every customer portal capability, governance pages, Audit, Activity, Customer Settings, and Agent. |
| Data Protection Officer | Customer portal | Authenticator code (TOTP) | Home, HITL, Data Residency, Compliance, and Login Activity. No dataset, project, role, user, Agent, or customer-settings access. |
| Security Officer | Customer portal | Authenticator code (TOTP) | The same governance surfaces as the DPO: Home, HITL, Data Residency, Compliance, and Login Activity. |
| RebelCore_SuperUser | Customer portal | Authenticator code (TOTP) | Every editable role flag, including Agent. It does not inherit Customer-Super-Admin-only Audit, Activity, Customer Settings, or governance-account access. |
| RebelCore_User | Customer portal | Authenticator code (TOTP) | Home, view Datasets, create/open Projects, view the Tree, and Agent. |
| RebelCore_AgentUser | Customer Agent | Email one-time code | Agent only. The Agent does not show a return link to the portal. |
| Custom role | Portal if any portal flag is on; otherwise Agent if only Access Agent is on | TOTP for portal; email code for Agent-only | Exactly the enabled role flags. If both portal and Agent access are enabled, sign-in lands in the portal and the user can open Agent from an authorised launcher. |
| CAS user | CAS | Authenticator code (TOTP) | Global provisioning and platform administration. CAS accounts are separate from customer roles. |
An active app user with neither a portal permission nor Access Agent has no valid destination and cannot complete sign-in. This is intentional: hiding navigation is not treated as the security boundary.
Permission-to-surface map
The role editor stores boolean flags. The front end uses them to show the relevant navigation and actions, and the API checks the same permissions independently.
| Permission or account type | What becomes available |
|---|---|
| View Datasets | Datasets navigation and dataset list. |
| Add Datasets | New import flow. Requires View Datasets. |
| Add Module | Module creation and build actions. Requires Add Datasets and View Datasets. |
| Add Projects | Projects navigation and project creation. |
| View Tree | Projects navigation and project Tree access. |
| Create Semantic Dataset | Build Semantic Dataset action in the Tree. |
| Delete Semantic Dataset | Delete action on semantic datasets. |
| Access Agent | Agent application, inference calls, and Agent launchers. |
| Add Users | Users navigation and user administration. |
| Add Roles | Roles navigation and role administration. |
| Customer Super Admin, DPO, or Security Officer | HITL, Data Residency, Compliance, and Login Activity. These governance capabilities are account-type access, not editable role flags. |
| Customer Super Admin only | Audit, Activity, and Customer Settings. |
The portal Home page is available to every account routed to the portal. A role change is picked up on the next page load or API request; the user does not need to sign out.
First sign-in and recovery
New users set their own password from the emailed invite link. Portal and governance users who have not enrolled in TOTP are taken through authenticator setup and receive one-time backup codes. Agent-only users skip authenticator enrolment and receive a six-digit email code on each sign-in.
For invite expiry, lockouts, backup codes, password reset, and sign-out behavior, see Signing in. For creating or changing the underlying permission bundle, see Roles & permissions.