The Basics
Permissions in Lumonic work through Roles. Think of a role as a job title that comes with specific access rights. You assign roles to team members, and those roles determine what they can do in Lumonic.
Note: This is for your firm's team members. Company CEO, CFOs and other reporter should be added separately here
Key concepts:
Role - Collections of permissions (e.g., "Financial Analyst", "Report Viewer")
Permissions - Rules that define what someone can do with specific resources
Resources - Things you're controlling access to (Entities, Dashboards, Fields, etc.)
Permission Levels
There are three permission levels, each building on the previous one:
1. READ - View data only (can't make changes)
2. WRITE - View and edit data (includes READ permission)
3. ADMIN - Full control including managing security/permissions (includes WRITE and READ)
What You Can Control Access To
Entities- Your main data containers (companies, properties, investments, etc.)
Namespaces - Groups of related entities
Clusters - Your overall workspace
Accessing Permissions & Adding Users
Accessing Permissions & Adding Users
In the left sidebar, click Team.
The Team page displays a list of all existing members, including:
First and Last Name
Email Address
Assigned Roles
Note: You must have administrative permissions to view or modify team members.
To add a new user:
Click the + Add User button in the upper-right corner of the Team page.
A pop-up window will appear.
Enter the new user’s details, including:
First Name
Last Name
Email Address
Assign one or more roles to the user.
Each role grants a unique set of permissions.
Users can hold multiple roles simultaneously.
Click Invite to confirm.
Manage & Create Roles
Manage & Create Roles
Roles are groups of users that you want to assign the same permissions to. Common examples are Auditor (read only), Deal Team, IR Team, etc.
Open the Permissions tab to view and manage roles.
Each role displays the following information:
Role Name
Description
Default Toggle (Y/N) — Determines whether this role is assigned to new users by default.
Associated Policies — Lists all policies applied to the role.
Assigned Users — Displays all users who currently hold the role.
Use the three-dot menu (⋮) on the right of each role to:
Edit the role’s details.
Delete the role
Create a new Role
The permissions each role has are called policies. Each role must have at least 1 policy assigned to it, but can have many.
Click the + Create Role button.
In the pop-up window:
Enter a Role Name and Description.
(Optional) Enable or disable the Default Role toggle. ***?
Assign Policies to the role.
A single role can include multiple policies.
The same policy can be reused across multiple roles.
Click Create role to finalize the role.
Manage & Create Policies
Manage & Create Policies
Policies dictate what permissions a user has.
Navigate to the Policies section (found within the Permissions tab).
Each policy includes:
Name
Access Level (Read, Write, or Admin)
Effect (Allow or Deny)
Resource Type (the component or area the policy applies to)
Details (a detail of the resource type)
Linked Roles (roles that include this policy)
Use the three-dot menu (⋮) on the right to Edit or Delete a policy.
Click + Create Policy.
In the policy creation window, specify the following:
Policy Name — Choose a clear, descriptive name.
Permission Type — Select the access level:
Read: View-only access.
Write: Can modify data but cannot manage permissions.
Admin: Full access, including the ability to create, edit, and assign policies or roles.
Effect: Determine whether the policy allows or denies access.
Resource Type: Specify the component this policy governs.
Resource Selector: Add any additional parameters or rules. **
Assigned roles: the roles in which you would like this policy to affect. **
Click Create Policy to create the policy.
Permission Inheritance
Permission Inheritance
Permissions flow down through a hierarchy:
Cluster → Namespace → Entity
This means:
If you grant someone WRITE access to a Namespace, they automatically get WRITE access to all Entities within it.
If you grant someone READ access to a Cluster, they can view everything in all Namespaces and Entities.
Tip: Start with broader permissions (Cluster/Namespace) for most users, and use specific Entity or Field permissions only when you need exceptions.
Allow vs. Deny Rules
Allow vs. Deny Rules
ALLOW rules grant access (most common).
DENY rules explicitly block access and always win over ALLOW rules.
Example: You might give a role WRITE access to all Entities (ALLOW), but DENY access to a specific sensitive Entity. The DENY rule overrides the broader ALLOW rule for that one entity.
Best Practices
Best Practices
Use descriptive role names — e.g., “Regional Analyst” is clearer than “Role 3.”
Start with least privilege — Give users the minimum access they need; add more as required.
Group similar users — Create roles for teams or functions, not individuals.
Test new roles — Pilot with one user before rolling out widely.
Review regularly — Periodically audit who has access to sensitive data.
Common Questions (FAQ)
Common Questions (FAQ)
Q: Can someone have multiple roles?
Yes. Users accumulate all permissions from all assigned roles. If one role grants READ and another grants WRITE, they’ll have WRITE access.
Q: What happens if I have both ALLOW and DENY for the same thing?
DENY always wins. This ensures restricted access can’t be accidentally granted.
Q: Can I give temporary access?
Permissions don’t expire automatically, but you can assign a role and remove it later when access is no longer needed.
Q: How do I know what access someone has?
Check the user’s assigned roles and review the permissions within each role. Remember: permissions are cumulative across roles.