Self-service organisation access is a binary feature that controls visibility boundaries for non-admin users. When enabled at the organisation level, Docupath enforces strict organisational silos: non-admin users only see documents within their assigned organisations, while admin users retain full visibility. Careful planning is required to avoid over-siloing and to ensure users have sufficient visibility for their roles.
How It Works
Understanding Self-Service Access Modes
Self-Service Disabled (Default)
When self-service is disabled at the organisation level:
All non-admin users see all documents across all organisations
Admin users see all documents
No visibility restriction based on organisation membership
Useful for centralised teams (e.g., shared finance department serving all sub-organisations)
Self-Service Enabled
When self-service is enabled at the organisation level:
Admin users see all documents
Non-admin users mapped to specific organisations see only documents from those organisations
Non-admin users not mapped to any organisation see all non-self-service documents
Useful for siloing data by department, region, or partner
Enabling Self-Service Access
Navigate to Settings in the left sidebar
Select Manage Organisations
Click on the parent organisation (or sub-organisation)
Check Enable Self-Service Access
Click Save
The feature is now active for the organisation. Users must be mapped via RBAC (Role-Based Access Control) to the organisation to see organisation-specific documents.
User Visibility Rules
The following visibility rules apply when self-service access is enabled:
User Type | Visibility |
Admin | All documents across all organisations |
Non-admin, mapped to Org A | Only documents assigned to Org A or its sub-organisations |
Non-admin, mapped to multiple orgs | Documents from all assigned organisations |
Non-admin, not mapped to any org | All non-self-service documents (from organisations with self-service disabled) |
Interaction with RBAC (Role-Based Access Control)
Self-service access works in conjunction with user role assignments:
Admin Role
Always sees all documents regardless of self-service status
Cannot be restricted by organisation mapping
Can assign themselves to organisations in RBAC settings
Responsible for enforcing data governance
Manager Role
If mapped to an organisation: Sees only that organisation's documents
Can manage documents, approvals, and rules within assigned organisations
If not mapped: See all non-self-service documents
Reviewer Role
If mapped to an organisation: Sees only that organisation's documents for review
Focuses on approval and rejection workflows within organisation scope
Cannot see documents outside assigned organisations
Validator Role (Paid)
If mapped to an organisation: Validates only within assigned organisation scope
Restricted by both role and organisation membership
Custom Roles
Custom roles respect organisation mapping:
Users with custom roles see only documents within assigned organisations (if self-service enabled)
Combine custom role permissions with organisation membership for granular control
Enabling Self-Service: Step-by-Step
Step 1: Enable Self-Service at Organisation Level
Settings > Manage Organisations
Open the target parent organisation or sub-organisation
Check Enable Self-Service Access
Click Save
Step 2: Map Users to Organisations via RBAC
Settings > User Management (or Settings > Access Control)
Click on the user to edit
Under Organisation Assignment, select which organisations this user can access:
Select one or more organisations from the dropdown
Save the changes
Repeat for each non-admin user
Step 3: Test Access Control
Log in as a non-admin user mapped to Organisation A
Verify that only documents from Org A are visible
Upload a test document; verify it is visible only to Org A members
Assign the document to Org B; verify it becomes invisible to Org A users
Repeat with other users and organisations
Step 4: Verify Admin Visibility
Log in as an admin user
Confirm that all documents across all organisations are visible
Test admin assignment of documents to different organisations
Configuration Examples
Example 1: Departmental Isolation
Scenario: Your organisation has separate Finance, Sales, and Operations departments.
Create three sub-organisations under parent:
Finance Sub-Org
Sales Sub-Org
Operations Sub-Org
Enable self-service access on each sub-organisation
Map users to their respective sub-organisations:
Finance staff → Finance Sub-Org only
Sales staff → Sales Sub-Org only
Operations staff → Operations Sub-Org only
Result: Finance users only see Finance documents; cannot access Sales or Operations data
Example 2: Partner Portal
Scenario: You manage documents for multiple external partners with strict data isolation.
Create a parent "Partners" organisation
Create sub-organisations for each partner:
Partner ABC Sub-Org
Partner XYZ Sub-Org
Partner DEF Sub-Org
Enable self-service access on each partner sub-organisation
Map partner-provided contractor users to their respective partner sub-organisations
Result: Partner ABC contractors only see Partner ABC documents; complete data isolation between partners
Example 3: Regional Offices with Shared Services
Scenario: Regional offices need local document visibility, but Finance team serves all regions.
Create parent organisation with sub-organisations:
North America Sub-Org (self-service enabled)
EMEA Sub-Org (self-service enabled)
APAC Sub-Org (self-service enabled)
Create a Finance Sub-Org under the same parent (self-service disabled)
Map users:
North America staff → North America Sub-Org only
EMEA staff → EMEA Sub-Org only
Finance staff → all Finance documents (no organisation restriction; self-service disabled)
Result: Regional staff see only their region's documents; Finance team has global visibility
Document Assignment and Visibility
When a document is assigned to an organisation:
Only users mapped to that organisation can see it (if self-service enabled)
Admin users always see it
Moving a document to a different organisation changes visibility:
Users in the old organisation lose access
Users in the new organisation gain access
Ensure document routing rules account for organisational boundaries
Risks of Over-Siloing
Overly restrictive organisation boundaries can create operational challenges:
Risk | Mitigation |
Users cannot collaborate across organisations | Use a shared services sub-organisation with self-service disabled for cross-functional teams |
Document routing failures if documents routed to wrong org | Implement clear document assignment rules; test with sample documents |
Cross-organisation relationships not visible | Admin users can see all relationships; ensure admin oversight of inter-org workflows |
Audit trail fragmentation | Centralised activity logging includes organisation context; enable logging retention across all orgs |
User frustration if too restrictive | Communicate access boundaries clearly; provide admin escalation path |
Training and support overhead | Document organisation structure and user access in knowledge base |
Best Practices for Self-Service Configuration
1. Plan Hierarchy Before Enabling Self-Service
Define your organisational structure and access requirements before enabling self-service:
Map out departments, regions, or partner boundaries
Document which users belong to which organisations
Identify cross-functional teams that need shared visibility
2. Use Admin Oversight
Assign at least one admin per parent organisation to oversee document routing
Admins can reassign documents between organisations if needed
Admins can grant temporary cross-organisation access for disputes or escalations
3. Create Shared Services Organisations
For cross-functional teams that need visibility across organisations:
Create a shared services sub-organisation with self-service disabled
Map cross-functional team members to this sub-organisation
These users see all documents; other users do not
4. Document Access Policies
Maintain a clear access policy document:
Which users belong to which organisations
Who can override organisation boundaries (e.g., admins, escalation managers)
How organisation assignments change with role transitions
Process for requesting cross-organisation access
5. Test Before Full Rollout
Enable self-service on a pilot organisation first
Map a subset of users and test visibility rules
Verify admin overrides work as expected
Monitor activity logs for unexpected access patterns
6. Communicate Changes
Inform users of organisation boundaries and their access
Provide documentation on how to request cross-organisation access
Set expectations on admin escalation processes
Disabling Self-Service Access
If self-service access needs to be disabled:
Navigate to Settings > Manage Organisations
Click on the organisation
Uncheck Enable Self-Service Access
Click Save
After disabling:
All non-admin users can see all documents from that organisation and below
Existing organisation mappings remain but are no longer enforced
Users in other organisations can access documents from this organisation
Supported Configurations and Options
Feature | Supported | Notes |
Self-service enablement | Yes | Per organisation; can vary between parent and sub-orgs |
Admin visibility | Yes | Always see all documents |
Non-admin scoping | Yes | Restricted to assigned organisations if self-service enabled |
Organisation assignment via RBAC | Yes | Users mapped to one or more organisations |
Cross-organisation access | No direct | Use shared services organisation with self-service disabled |
Admin override | Yes | Admins can assign documents to any organisation |
User notification on visibility | Optional | Can configure email when user loses access to document |
Activity logging | Yes | Logs include visibility boundaries and access grants |
Sub-organisation inheritance | Yes | Sub-org can inherit or override parent self-service setting |
Technical Specifications
Parameter | Specification |
Self-service scope | Per organisation (parent and sub-org) |
Visibility model | Non-admin users see only assigned organisations; admins see all |
Organisation assignment | One or more organisations per non-admin user |
User without organisation | Sees all non-self-service documents |
Admin role visibility | Unaffected by self-service setting; always full visibility |
Manager role visibility | Scoped by organisation assignment if self-service enabled |
Reviewer role visibility | Scoped by organisation assignment if self-service enabled |
Validator role visibility | Scoped by organisation assignment if self-service enabled |
Document routing | Assigns document to single organisation; visibility determined by assignment |
Activity logs | Logs include organisation context; searches can filter by organisation |
Audit trail | Shows visibility boundaries applied at processing time |
Integration Points
RBAC (Role-Based Access Control): User role + organisation assignment determines visibility
Document Processing: Document assigned to organisation during upload or processing
Rejection Notifications: Visible only to users with access to the organisation
Activity Logs: Can be filtered by organisation; shows visibility boundaries
Data Export: Export respects visibility boundaries; non-admin users export only their visible documents
Instruction Builds: Organisation-scoped instructions apply; users see only their org's instructions
Transformation and Rejection Rules: Organisation-scoped rules apply; visibility unchanged
Sub-Organisation Hierarchy: Sub-org can inherit or override parent's self-service setting
Known Limitations and Edge Cases
Limitation | Workaround |
Single organisation assignment per document | Documents belong to one organisation; cannot assign to multiple simultaneously |
No dynamic visibility rules | Visibility static once document is assigned; must manually reassign to change |
Cross-organisation relationships obscured | Non-admin users cannot see partners in other organisations; admin must broker communication |
Audit trail visibility scoping | Non-admin activity logs filtered to their organisations; cross-org patterns may be missed |
Parent/child organisation visibility | Sub-org documents visible only to sub-org members; parent members need explicit access |
User without organisation gets broad access | Non-admin unmapped users see all non-self-service documents; use assignment to restrict |
Self-service disable cascading | Disabling self-service at parent may not auto-disable at sub-org; must manually disable per level |
Email notification dependencies | Rejection notifications only sent to users with visibility; check email forwarding if issues occur |
Admin responsibility | Over-reliance on admin escalation for cross-org access; plan governance model |
Migration challenges | Enabling self-service on live systems may immediately restrict user access; test in staging first |