Understanding ARPIA's Permission System
🔐 Understanding ARPIA's Permission System
Before adding users or configuring access in ARPIA, it's essential to understand how the permission system works. ARPIA uses two concepts to control who can do what inside a Workarea: the Super User Security Profile and custom Security Profiles.
👑 The Super User Profile
When a Workarea is created, a Super User Security Profile is automatically generated and assigned to the creator of the Workarea.
Unlike other Security Profiles, the Super User profile:
- ✅ Is created automatically — it does not need to be built manually
- ✅ Has full, unrestricted access to everything inside the Workarea
- ✅ Can manage all users, profiles, settings, and platform features
- ✅ Can be assigned to any user by a Workarea administrator
- ✅ Remains available as a profile in the Workarea at all times
The Super User profile is extremely sensitive. A user assigned this profile has unrestricted access to the entire Workarea — including all data, settings, users, and configurations. Assign it with care.
Workarea Ownership and Handoff
The Super User profile is initially assigned to whoever creates the Workarea. Once the Workarea is fully configured, the designated administrator within your organization can be assigned the Super User profile, transferring full administrative control.
Data Privacy Note: Access to Workarea data is governed entirely by your organization's Security Profiles. Only users explicitly assigned a Security Profile by your Workarea administrator can access the platform and its data. ARPIA enforces tenant isolation — each Workarea is fully scoped to its organization.
🛡️ Security Profiles
Security Profiles are custom permission sets that define what a user can see and do inside the Workarea.
Beyond the built-in Super User profile, all other Security Profiles must be created manually by a Workarea administrator before users can be added.
Critical: A brand new Workarea has only the Super User profile available. All other profiles (ADMIN, DEV, USER, VIEWER, etc.) must be created manually before adding regular users.
What a Security Profile controls:
- Access to platform modules (Knowledge Catalog, Reasoning Flows, AI Apps, etc.)
- Read vs. write vs. admin permissions per module
- Access to specific Knowledge Nodes
- Visibility of dashboard resources
🔄 How They Work Together
Workarea Created
│
└── Super User Profile generated automatically
│
├── Assigned to Workarea creator by default
│
├── Administrator creates additional Security Profiles
│ (ADMIN, DEV, USER, VIEWER, etc.)
│
├── Users are added to the Workarea
│
└── Each user is assigned a Security Profile
│
└── User accesses the platform
based on their assigned profile
A user without a Security Profile assigned cannot access the Workarea.
🔑 Login Methods
When adding a user, the Workarea administrator also sets the Login Method:
| Method | Description |
|---|---|
| Password | User logs in with email + password |
| Google SSO | User logs in via Google Workspace |
| Microsoft SSO | User logs in via Microsoft 365 / Azure AD |
Login method is set at user creation. If you need to switch an existing user to SSO, this must be done from the Workarea where the user was originally created.
📋 Key Rules to Remember
- The Super User profile is created automatically with every new Workarea
- It is assigned to the Workarea creator by default, but can be reassigned
- Treat the Super User profile as a high-privilege, sensitive asset
- All other Security Profiles must be created before users are added
- Every user must have a Security Profile assigned to access the platform
- Access to Workarea data is controlled exclusively by your organization's administrators
- Login method (Password vs SSO) is a per-user setting, configured at creation
- SSO requires your ARPIA link to be whitelisted by your IT admin
What's Next
Now that you understand the permission model, you're ready to:
- 🔗 First-Time Workarea Setup — set up profiles and add your team
- 🔗 How to Create a Security Profile — build your permission sets
- 🔗 How to Create a User — add team members
- 🔗 Single Sign-On (SSO) — configure passwordless login