Self-Service Access is an on/off setting on each organization that controls document visibility for non-admin users. When it is enabled, Docupath keeps that organization siloed: non-admin users see only documents in the organizations they are mapped to, while admins keep full visibility. Plan the boundaries before turning it on, so that people still see everything their job needs.
How It Works
Understanding Self-Service Access Modes
Self-Service Disabled (Default)
When self-service is disabled on an organization:
All non-admin users see that organization's documents, whether or not they are mapped to it
Admin users see all documents
There is no visibility restriction based on organization membership
Useful for centralized teams (e.g., a shared finance department serving all sub-organizations)
Self-Service Enabled
When self-service is enabled on an organization:
Admin users see all documents
Non-admin users mapped to specific organizations see only documents from those organizations
Non-admin users not mapped to any organization see all non-self-service documents
Useful for siloing data by department, region, or partner
The organization itself still appears in the organization list used by filters, which every user can see. Self-Service Access limits which documents people see, not which organizations exist.
Enabling Self-Service Access
Navigate to Settings in the left sidebar
Select Manage Organizations
Click on the parent organization (or sub-organization)
Check Enable Self-Service Access
Click Save
Self-Service Access applies to that organization as soon as it is saved. Users must be mapped to the organization on the Users tab under Settings → Manage Users & Roles before they can see its documents.
User Visibility Rules
The following visibility rules apply when self-service access is enabled:
User Type | Visibility |
Admin | All documents across all organizations |
Non-admin, mapped to Org A | Only documents assigned to Org A or its sub-organizations |
Non-admin, mapped to multiple orgs | Documents from all assigned organizations |
Non-admin, not mapped to any org | All non-self-service documents (from organizations with self-service disabled) |
How Roles and Organization Mapping Work Together
Self-Service Access works alongside the role a user holds. The role sets which modules and actions someone gets; the organization mapping sets which documents they get those actions on.
Admin
Always sees all documents regardless of self-service status
Cannot be restricted by organization mapping
Can map any user, including themselves, to organizations on the Users tab
Responsible for enforcing data governance
Manager
If mapped to an organization: sees only that organization's documents
Works on documents, approvals, and organization-level rules within the assigned organizations
If not mapped: sees all non-self-service documents
Reviewer
If mapped to an organization: sees only that organization's documents for review
Approves and rejects within the organization scope
Cannot see documents outside the assigned organizations
Validator
If mapped to an organization: validates only within the assigned organization scope
Restricted by both role and organization membership
Reviewer and Validator
Reviews and validates, and is scoped exactly like a Reviewer or a Validator
If mapped to an organization: sees only that organization's documents
Custom Roles
Custom roles respect organization mapping in the same way as system roles:
Users holding a custom role see only documents within their assigned organizations (if self-service is enabled)
A role decides which modules and actions a user gets; organization mapping decides which documents they get. Set both to scope someone precisely
Because one custom role is assigned to many users, map organizations per user rather than expecting the role to narrow document visibility on its own
Enabling Self-Service: Step-by-Step
Step 1: Enable Self-Service on the Organization
Go to Settings → Manage Organizations
Open the target parent organization or sub-organization
Check Enable Self-Service Access
Click Save
Step 2: Map Users to Organizations
Go to Settings → Manage Users & Roles and open the Users tab
Click the user you want to edit
Under Organization Assignment, select which organizations this user can access:
Select one or more organizations from the dropdown
Save the changes
Repeat for each non-admin user
Step 3: Verify Non-Admin Visibility
Sign in as a non-admin user mapped to Organization 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 drops out of view for Org A users
Repeat with other users and organizations
Step 4: Verify Admin Visibility
Sign in as an admin user
Confirm that all documents across all organizations are visible
Confirm that the admin can assign documents to different organizations
Configuration Examples
Example 1: Departmental Isolation
Scenario: Your organization has separate Finance, Sales, and Operations departments.
Create three sub-organizations under parent:
Finance Sub-Org
Sales Sub-Org
Operations Sub-Org
Enable self-service access on each sub-organization
Map users to their respective sub-organizations:
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; they 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" organization
Create sub-organizations for each partner:
Partner ABC Sub-Org
Partner XYZ Sub-Org
Partner DEF Sub-Org
Enable self-service access on each partner sub-organization
Map partner-provided contractor users to their respective partner sub-organizations
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 the Finance team serves all regions.
Create parent organization with sub-organizations:
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
APAC staff → APAC Sub-Org only
Finance staff → no organization mapping, so they are not limited to one organization
Result: Regional staff see only their region's documents, and the Finance team sees the documents of every organization that does not have self-service enabled, including the Finance Sub-Org
Document Assignment and Visibility
When a document is assigned to an organization:
Only users mapped to that organization can see it (if self-service enabled)
Admin users always see it
Moving a document to a different organization changes visibility:
Users in the old organization lose access
Users in the new organization gain access
Ensure document routing rules account for organizational boundaries
Risks of Over-Siloing
Overly restrictive organization boundaries can create operational challenges:
Risk | Mitigation |
Users cannot collaborate across organizations | Use a shared services sub-organization 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-organization relationships not visible | Admin users can see all relationships; ensure admin oversight of inter-org workflows |
Audit trail fragmentation | Activity Logs record organization context, and admins can review activity across every organization |
User frustration if too restrictive | Communicate access boundaries clearly; provide admin escalation path |
Training and support overhead | Document organization structure and user access in knowledge base |
Best Practices for Self-Service Configuration
1. Plan Hierarchy Before Enabling Self-Service
Define your organizational structure and access requirements before enabling self-service:
Map out departments, regions, or partner boundaries
Document which users belong to which organizations
Identify cross-functional teams that need shared visibility
2. Use Admin Oversight
Assign at least one admin per parent organization to oversee document routing
Admins can reassign documents between organizations if needed
Admins can grant temporary cross-organization access for disputes or escalations
3. Create Shared Services Organizations
For cross-functional teams that need visibility across organizations:
Create a shared services sub-organization with self-service disabled
Leave the cross-functional team members unmapped, so they see the documents of every organization that does not have self-service enabled
Map a user to a specific organization only when they should be limited to that organization's documents
4. Document Access Policies
Maintain a clear access policy document:
Which users belong to which organizations
Who can override organization boundaries (e.g., admins, escalation managers)
How organization assignments change with role transitions
Process for requesting cross-organization access
5. Test Before Full Rollout
Enable self-service on a pilot organization 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 organization boundaries and their access
Provide documentation on how to request cross-organization access
Set expectations on admin escalation processes
Disabling Self-Service Access
If self-service access needs to be disabled:
Navigate to Settings → Manage Organizations
Click on the organization
Uncheck Enable Self-Service Access
Click Save
With self-service off:
All non-admin users can see all documents from that organization and below
Existing organization mappings stay in place but do not limit document visibility
Users in other organizations can access documents from this organization
Supported Configurations and Options
Feature | Supported | Notes |
Self-service enablement | Yes | Per organization; can vary between parent and sub-orgs |
Admin visibility | Yes | Always see all documents |
Non-admin scoping | Yes | Documents restricted to the assigned organizations if self-service enabled |
Organization assignment | Yes | Users mapped to one or more organizations on the Users tab |
Cross-organization access | No direct | Use shared services organization with self-service disabled |
Admin override | Yes | Admins can assign documents to any organization |
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-organization inheritance | Yes | Sub-org can inherit or override parent self-service setting |
Other Technical Specifications
Parameter | Specification |
Self-service scope | Per organization (parent and sub-org) |
Visibility model | Non-admin users see only the documents of their assigned organizations; admins see all documents. The organization list used by filters stays visible to every user |
Organization assignment | One or more organizations per non-admin user |
User without organization | Sees all non-self-service documents |
Admin role visibility | Unaffected by self-service setting; always full visibility |
Manager role visibility | Scoped by organization assignment if self-service enabled |
Reviewer role visibility | Scoped by organization assignment if self-service enabled |
Validator role visibility | Scoped by organization assignment if self-service enabled |
Reviewer and Validator role visibility | Scoped by organization assignment if self-service enabled |
Custom role visibility | Scoped by organization assignment if self-service enabled, same as a system role |
Document routing | Assigns document to single organization; visibility determined by assignment |
Activity Logs | Logs include organization context; searches can filter by organization |
Audit trail | Shows visibility boundaries applied at processing time |
Integration Points
Manage Users & Roles: the user's role decides which modules and actions they get, and Organization Assignment decides which documents they see
Document Processing: Document assigned to organization during upload or processing
Rejection Notifications: Visible only to users with access to the organization
Activity Logs: Can be filtered by organization; shows visibility boundaries
Data Export: Export respects visibility boundaries; non-admin users export only their visible documents
Instruction Builds: Organization-scoped instructions apply; users see only their org's instructions
Transformation and Rejection Rules: Organization-scoped rules apply; visibility unchanged
Sub-Organization Hierarchy: Sub-org can inherit or override parent's self-service setting
Known Limitations and Edge Cases
Limitation | Workaround |
Single organization assignment per document | Documents belong to one organization; cannot assign to multiple simultaneously |
No dynamic visibility rules | Visibility static once document is assigned; must manually reassign to change |
Cross-organization relationships obscured | Non-admin users cannot see partners in other organizations; admin must broker communication |
Audit trail visibility scoping | Non-admin Activity Logs are filtered to their organizations; cross-org patterns may be missed |
Parent/child organization visibility | Sub-org documents visible only to sub-org members; parent members need explicit access |
User without organization 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 |
Enabling on an active tenant restricts access immediately | Enable it on a pilot organization first and map users before rolling it out to everyone |