Child Organizations

Child organizations are subsidiary organizations of your main Proof organization. As you scale your usage of Proof, you may want to support multiple use cases or teams within your business. Each use case might have its own unique set of stakeholders, as well as its own specific needs and configurations that differ from other use cases. Using child (subsidiary) organizations within your Proof org, you can create an organizational hierarchy that meets your various business needs, creates separation where needed, and keeps things organized for your team.

If you'd like to create a parent/child organization structure, please reach out to [email protected] or your Proof customer team.

Siloed Transaction Access

A member of an organization will only have access to transactions/settings in that organization, and transactions/settings in any children of that organization. See the example org tree below:

In this example, Jane Doe can see and create transactions created in the Dev Docs, Inc., Dev Docs - Legal, and Dev Docs - Wealth Management.

Cathy Smith can only see and create transactions in Dev Docs - Legal.

Alice Chen can only see and create transactions in Dev Docs - Wealth Management.

Customize Each Use Case

Each child account comes with its own fresh set of configurations. Any organization settings you set in your parent account can be set differently in any of your child accounts. This lets you customize your Proof experience across your business, on a more localized basis. Using child orgs, settings such as document templates, transaction MFA, custom email content, co-branding, SSO, and webhooks can be customized on a per-use-case basis.

Some common use cases for creating child organizations include:



• Multiple business subsidiaries owned/managed by a parent entity. Separate child organizations allows for a 1:1 relationship between organizations and custom branding.
• Effectively allows for per-transaction control over settings that can otherwise only be set per-organization. For example, a parent org could have batch signing enabled while a child org has the setting disabled. The transaction creator can route transactions to either organization depending on needs/requirements for a given transaction.
• Segmenting transaction visibility between organization members. Parent organization members can view all transactions associated with an organization tree. Child organization members can only see the transactions created in their associated child organization.