Skip to main content
Version: Current

Deep Dive: Permissions Framework

Introduction​

Zudello's permissions framework is designed to provide granular control over user access, ensuring users can perform their required tasks while maintaining data security and compliance. It governs two key aspects:

  1. What actions can a user perform? (e.g., view, create, update, delete, approve specific document types) - Controlled by Access Permissions assigned via User Groups.
  2. What data can a user see or interact with? (e.g., only documents they submitted, only documents for a specific department, only specific suppliers) - Controlled by Data Permissions assigned via User Groups.

Understanding how these components work together is essential for administrators configuring user access within Zudello.

Core Components​

1. Users​

  • The fundamental entity representing an individual interacting with Zudello.
  • Associated with an Organisation and one or more Teams.
  • Permissions are not assigned directly to users but inherited through User Group membership.

2. User Groups​

  • Containers used to assign permissions and data access rules to multiple users efficiently.
  • Managed at the Organisation level (Organisation Settings > User Groups).
  • Users are assigned to groups within specific Teams (Organisation Settings > Group Membership).
  • A user can belong to multiple groups within a team; their effective permissions are the sum of all permissions granted by those groups.
  • Types of User Groups:
    • Access Group: The primary type used to grant Access Permissions (defining actions users can perform).
    • Visibility Group: Used to assign Data Permissions (defining data users can see/interact with). While Data Permissions are configured separately (see below), they are linked to users via Visibility Groups.
    • Approval Group: Can be used specifically in "Get Approval" Sentence actions to route approvals to a dynamic list of users. Functionally similar to Access/Visibility groups but often used semantically for approval routing.
    • Legacy Group: Older group types, generally migrated to Access/Visibility.

3. Access Permissions​

  • Define what actions a user can perform within specific modules and submodules.
  • Assigned to Access Groups.
  • Follow a # notation: {MODULE}:{SUBMODULE}#{PERMISSION} (e.g., PURCHASING:INVOICE#VIEW, RELATIONSHIPS:SUPPLIER#CREATE).
  • Common Permissions:
    • #VISIBLE: Allows the user to see the Module/Submodule menu icon. Essential for navigation.
    • #VIEW: Allows viewing of individual records within the submodule.
    • #CREATE: Allows creation of new records.
    • #UPDATE: Allows editing/saving existing records.
    • #DELETE: Allows deletion of records (use with caution).
    • #ARCHIVE: Allows archiving of records.
    • #REVERT: Allows reverting records from certain statuses.
    • #APPROVE: Allows approving/rejecting via the main buttons (user must also be assigned the step).
    • #FORCE_APPROVE: Allows bypassing an approval step (Admin action).
    • #CHANGE_APPROVER: Allows changing the assigned approver.
    • #PLACE_ORDER: Allows using the Place Order action on POs.
    • #RECEIVE: Allows using the Create Goods Receipt action.
    • #IMPORT, #EXPORT: Allows using data import/export tools.
    • #CHAT, #AUDIT, #AUDIT_LOG: Control access to specific sidebar features.
    • ...and many others specific to modules or features.

4. Data Permissions​

  • Define which specific records a user can see or interact with, acting as filters on top of Access Permissions.
  • Configured at the Team level (Settings > General > Data Permissions).
  • Linked to users via Visibility Groups.
  • Rules are defined per Model (e.g., Transaction, Supplier, Item).
  • Rule Logic:
    • All: Grants access to all records of the specified Model (subject to Access Permissions).
    • Own: Grants access only to records where the user has a direct relationship (e.g., they are the created_by user, submitted_by user, or listed in the assignees array).
    • Related: Grants access based on a relationship to another record the user can access. (e.g., View Transactions where Supplier is Own - allows viewing invoices if the user owns the linked supplier record).
    • Specific: Grants access only to explicitly listed records (e.g., view only Supplier A and Supplier B).

Configuration Process​

  1. Define Roles: Identify the different user roles within the organisation (e.g., AP Clerk, Purchasing Manager, Project Approver, Finance Admin).
  2. Create User Groups: In Organisation Settings > User Groups, create Access and Visibility groups corresponding to these roles (e.g., "AP Clerk Access", "AP Clerk Visibility - Dept A", "Manager Access", "Manager Visibility - Own Team").
  3. Assign Access Permissions: Edit each Access Group and assign the necessary action permissions (e.g., PURCHASING:INVOICE#VISIBLE, #VIEW, #UPDATE for "AP Clerk Access").
  4. Configure Data Permissions: In Team Settings > General > Data Permissions, create rules to define data visibility filters (e.g., Rule Name: "View Own Invoices", Model: Transaction, Field: submitted_by, Operator: Own).
  5. Assign Data Permissions to Groups: Edit each Visibility Group and link the relevant Data Permission rules to it.
  6. Assign Users to Groups: In Organisation Settings > Group Membership, select a Team, then select a User, and assign them to the appropriate Access and Visibility groups for that team.

Interaction: Access vs. Data Permissions​

Crucially, a user needs both the required Access Permission and the necessary Data Permission to interact with a record.

  • Example: User Alice is in the "AP Clerk Access" group (granting PURCHASING:INVOICE#UPDATE) and the "AP Clerk Visibility - Dept A" group (granting Data Permission to view Invoices where Department = Dept A).
    • Alice can update Invoice #123 because it's coded to Dept A.
    • Alice cannot update Invoice #456 (coded to Dept B) because her Data Permissions filter it out, even though she has the #UPDATE Access Permission.
    • User Bob is in the "AP Clerk Access" group but no Visibility group. He has the #UPDATE permission but cannot see any invoices because he lacks Data Permissions.

Practical Examples​

  • Scenario 1: AP Clerk for Subsidiary A
    • Goal: View/Update Invoices & Credits, but only for Subsidiary A. View related Suppliers.
    • Access Group: PURCHASING:INVOICE#VISIBLE, #VIEW, #UPDATE; PURCHASING:CREDIT#VISIBLE, #VIEW, #UPDATE; RELATIONSHIPS:SUPPLIER#VISIBLE, #VIEW.
    • Data Permissions Rule: Name: "Subsidiary A Data", Model: Transaction, Field: Subsidiary, Operator: Specific, Value: [Select Subsidiary A]. (Also need a rule for Suppliers linked to Sub A).
    • Visibility Group: Link the "Subsidiary A Data" rule.
  • Scenario 2: Project Manager
    • Goal: View/Approve POs and Invoices coded to their specific Projects.
    • Access Group: PURCHASING:ORDER#VISIBLE, #VIEW, #APPROVE; PURCHASING:INVOICE#VISIBLE, #VIEW, #APPROVE.
    • Data Permissions Rule: Name: "Own Project Docs", Model: Transaction, Field: Project, Operator: Own. (Assumes the PM is linked to the Project record, e.g., as an owner or assignee).
    • Visibility Group: Link the "Own Project Docs" rule.
  • Scenario 3: Manager Access (View Direct Reports' Submissions)
    • Goal: View documents submitted by their direct reports.
    • Access Group: Relevant #VISIBLE, #VIEW permissions for document types.
    • Data Permissions Rule: Name: "Direct Reports Submissions", Model: Transaction, Field: submitted_by.manager, Operator: Own. (Requires manager field to be correctly populated on User profiles).
    • Visibility Group: Link the "Direct Reports Submissions" rule.

Best Practices​

  • Role-Based Access Control (RBAC): Design groups around job roles rather than individual users.
  • Principle of Least Privilege: Grant only the minimum permissions necessary for a user to perform their job function.
  • Separation of Duties: Use distinct groups for different responsibilities where appropriate (e.g., separate groups for creating POs vs. approving them).
  • Regular Audits: Periodically review group memberships and assigned permissions to ensure they are still appropriate.
  • Clear Naming Conventions: Use descriptive names for User Groups and Data Permission rules.
  • Test Thoroughly: Impersonate users or use test accounts to verify that permissions and data restrictions work as expected.

Troubleshooting​

If users report access issues:

  1. Verify Group Membership: Check which groups the user belongs to in the relevant Team (Organisation Settings > Group Membership).
  2. Check Access Permissions: Review the permissions assigned to the user's Access Groups. Do they have the necessary action permission (e.g., #UPDATE)?
  3. Check Data Permissions: Review the rules linked to the user's Visibility Groups. Are there rules filtering out the data they need access to? Is the data on the record correct (e.g., correct Department coding)?
  4. Check Both: Remember the user needs both appropriate Access and Data Permissions.

Refer to: