Organizations are the structural backbone of a Docupath tenant, defining how documents are routed, how rules are scoped, and how user access is controlled. Docupath uses a two-level hierarchy - parent organizations and sub-organizations - to model real-world business structures such as holding companies, regional branches, departments, or external partner entities.
Every instruction build, transformation rule, and rejection rule can be scoped to a specific organization, making the organization model the primary mechanism for applying targeted business logic at scale.
How It Works
Organization Hierarchy
Docupath tenants are structured into parent organizations and sub-organizations:
Parent Organization: Represents the main entity (e.g., a company or holding group). It defines the core inbox, rules, and access settings. When created, Docupath generates a unique email address for document ingestion.
Sub-Organization: Sits under a parent and represents branches, departments, regions, or subsidiaries. Sub-organizations inherit settings from their parent but allow granular overrides for rules, trading parties, and access controls.
Organization Creation
When creating a parent organization, administrators define the organization name and configure three optional behavior flags:
Urgent Flag: Marks all incoming documents from this organization as high priority
Self-Service Access: Restricts document and user visibility to mapped users only - ideal for external partners or sensitive workstreams
Split documents from this organization: Turns on automatic document splitting for documents arriving under this organization. A file that contains several business documents is separated into one document per part, each processed on its own. See Document Splitting.
Sub-organizations require a name and email, and inherit the parent's Urgent, Self-Service, and split-documents settings, which can be overridden at the sub-organization level.
Override Trading Party
A sub-organization can assign one of its trading parties as the overriding trading party. When enabled, every document routed into that sub-organization automatically has its Primary Party set to the override value - regardless of what the document itself states. This ensures consistent party assignment for organizations that process documents on behalf of a single entity.
Self-Service Access
When self-service is enabled on an organization:
Users mapped to that organization see only documents they uploaded or those assigned to the organization
The organization and its documents are hidden from non-admin users who are not explicitly mapped
Admins retain full visibility across all organizations, including self-service ones
How Organizations Power Automation
Once defined, organizations become scoping boundaries for the entire business logic layer:
Feature | How Organization Scoping Works |
Instruction Builds | Apply extraction logic specific to each organization's document patterns |
Transformations | Define formatting and value manipulation rules per organization |
Rejection Rules | Block non-conforming documents from specific organizations |
Enrichment | Autofill fields using saved organization identifiers and trading party data |
Supported Configurations and Options
Configuration | Detail |
Parent organization fields | Name, Urgent Flag, Self-Service Access, Split documents from this organization |
Sub-organization fields | Name, Email, Urgent (inherited), Self-Service (inherited), Split documents (inherited), Override Trading Party |
Document splitting | Off by default; set per organization and per sub-organization. Changing it on a parent updates every sub-organization still following the parent |
Self-service visibility | Admin: all organizations visible; Non-admin mapped: only assigned orgs; Non-admin unmapped: all non-self-service orgs |
Email address | Auto-generated per parent and sub-organization for email ingestion |
Override trading party | Assign one trading party per sub-organization as automatic Primary Party |
Other Technical Specifications
Parameter | Limit |
Maximum organizations per tenant | 100 |
Maximum sub-organizations per organization | 100 |
Maximum instruction builds per organization | 100 |
Maximum rule groups per organization | 100 |
Integration Points
Document routing: Documents uploaded via email are routed to sub-organizations based on Primary Party matching against override trading parties
Rule scoping: Instruction Builds, Transformations, and Rejection Rules can all be scoped at the organization level, sitting between Country and Trading Party in the precedence hierarchy
User access control: Organization assignment determines which documents non-admin users can see and act on
API uploads: Sub Organization ID must be included in API upload requests to route documents correctly
Email ingestion: Each organization and sub-organization has a unique email address for document submission
Notes
If organizations are not set up correctly, documents may fail validation or visibility checks
Self-service access restricts all non-admin visibility - combining with role-based access is recommended for layered security
Override trading party applies to all documents in the sub-organization without exception; it cannot be conditionally applied
Email ingestion to the parent organization requires Primary Party matching for sub-organization routing - if no match or multiple matches occur, the document is flagged as "No sub organization detected"
Organization names should be unique and descriptive; ambiguous names can cause confusion in rule scoping and reporting
Deleting an organization does not delete its associated documents, but prevents new document routing to it