Access in Elementum is built around two ideas that drive every decision in this section:Documentation Index
Fetch the complete documentation index at: https://docs.elementum.io/llms.txt
Use this file to discover all available pages before exploring further.
- Roles and permissions determine what a user can do — create records, edit apps, run automations, invite other users.
- Object data access policies determine what a user can see — which specific records appear in lists, search, and reports.
Ways to Create Users
Users can enter your Elementum organization through three paths. Pick the one that matches your operating model — they all land users in the same access model, so the choice is about lifecycle automation, not capability.- Manual creation in Organization Settings — An admin invites users from Org Settings → Groups (recommended) or Org Settings → Users. The user receives an email and self-completes registration. Best for small teams, ad-hoc invites, and external collaborators. See Users.
- Single Sign-On (SSO) — Users authenticate through your Identity Provider. With Auto Create Unknown Users enabled, Elementum creates the user account on their first SSO login. Best for organizations that want centralized authentication without automated lifecycle management. See SSO with SAML 2.0.
- SCIM provisioning — Your IdP pushes user and group changes to Elementum, so accounts exist in Elementum before a user logs in. Best for organizations that need automated onboarding, profile syncing, and deactivation tied to identity-system membership. See SCIM Provisioning.
Recommended Setup Order
Set your organization up in this order before inviting users. Each step builds on the one before it, and skipping ahead almost always results in rework.Configure your email domains
Define the email domains that belong to your organization. Domains are the foundation for nearly everything that follows: they drive dynamic groups, gate the User Invite Policy, and identify users coming in through your Identity Provider.Get this list right first — changes here ripple into every group and policy that references a domain.
Create your groups
Build the groups that mirror how your organization actually works — typically by team, function, or location.
- Use dynamic groups when membership can be derived from email domain (for example, “All Employees” or “All Contractors”).
- Use manually managed groups for stable, intentional teams (for example, an approval committee or a small admin group).
Attach groups to roles and permissions
Assign each group to the roles and permissions it needs. For every role, decide whether it belongs at the organization level or the object level — see Org-level vs Object-level Roles below.Granting a role to a group means every current and future member inherits the same capabilities, so changes to the group propagate automatically.
Define object data access policies
Use object data access policies to control which records each group can see. Policies are the right place to express “this team only sees their own records,” “managers see their direct reports’ records,” or “external partners only see records they were invited to.”Apply policies to groups, not individual users, so a user’s visibility moves with their group membership.
Invite users and add them to groups
Now invite users and add them to the appropriate groups. Because roles and data access are already attached to those groups, every new user inherits the correct capabilities and visibility immediately, with no per-user configuration required.
Following this order is the difference between onboarding a new hire in seconds (add to a group) and onboarding them over hours (configure roles, permissions, and data access on each individual account).
Roles vs. Object Data Access
These two systems work together but answer different questions. Configure both for every group.| Roles & Permissions | Object Data Access | |
|---|---|---|
| What it controls | What a user can do | What a user can see |
| Examples | Create records, edit apps, run automations, invite users | Which specific records appear in lists, search, and reports |
| Where it is configured | Org Settings → Roles & Permissions, or Roles & Permissions under an app’s Security menu | App → Security → Data Access |
| Best assigned to | Groups | Groups |
Org-level vs Object-level Roles
When you assign or create a role, choose its scope deliberately. Picking the wrong scope is the most common cause of access drift over time.- Organization-level roles apply across every app, element, and task the user can reach. Use them for administrative oversight responsibilities — IT admins, compliance officers, security operators, platform admins — where the role should cascade everywhere.
- Object-level roles (also called app-, element-, or task-level roles) apply only inside a single object. Use them for department- or workflow-specific responsibilities — a vendor risk app’s reviewers, a procurement app’s buyers, an incident app’s responders — where the role only makes sense within that workflow.
Continue Reading
Groups
Organize users into groups for scalable role and access assignment
Roles & Permissions
Decide what each group can do across the organization or within a specific object
Object Data Access
Control which records each group can see using dynamic policies
Users
Invite users into your organization and assign them to groups
Service Accounts
Create dedicated, auditable identities for automations and agents
Single Sign-On (SAML)
Centralize authentication through your existing Identity Provider
External User Re-Authentication
Require periodic re-verification for users in the External Users group