For larger organizations that have different brands or if you are a franchisor and your franchisees are going to be using the system, it might make sense for you to utilize our Multi-org Structure.
The multi-org structure allows you to break up your organization into separate child orgs for easier management and data separation.
The rest of this article will be spent explaining the Multi-org structure.
Description of the Multi-Org Structure
The multi-org structure has a parent-to-child relationship.
The original organization is often referred to as the Parent Org, it is usually the corporate org, and it can dictate what the children can see and do.
There can be an unlimited amount of children orgs to a single parent, this isn't recommended.
Since we can have so many levels of orgs we use the following terminology to describe orgs at different levels of the hierarchy.
Ancestor Org is an org that is above an Org.
Descendant Org is an org that is below an Org.
In the image above Child Org 1 is the Ancestor Org to Child Org 2 and the Descendant Org to the Parent Organization.
Parents can provide checklists to their children, through inheritability, which their children can use but not edit.
The concept of inheritability applies to other aspects of the platform, Locations, Scripts, Roles, Tags, Filters, etc.. the parent provides access, which the child can use but not edit or change the entity.
Parent users, with proper roles, can move to the children's orgs to review data and conduct checklists. Locations live in the Child Orgs.
Parents can set up roles for children's orgs and control how much access to the platform they grant their children.
One of the biggest benefits of the Org Structure is that Child Orgs, when allowed by parents, can set up their own processes and management structures.
This means that the parent can get the child to do what they want and give them some autonomy to do their own thing.
In the flow chart diagram above, the child orgs are siblings. Each org is a child of the parent but they exist as their own entities, they have no concept of the parent or their other sibling orgs. Their data never mix or is exposed to other siblings.
Child orgs are hard and fast data containers and you cannot move entities, checklists, tags, locations, etc.. between them.
The question you need to ask yourself when deciding whether or not to use the multi-org structure is this: will I ever let my franchisees or brands have control of their platforms within my organization?
If the answer is yes, I want my locations to be able to create their own checklists, manage their own users, and basically have the ability to do more than what I'm mandating or willing to administrate for them. Then the answer is Yes, the multi-org structure is for you.
If you are going to create a world where the locations and users in your platform will only do what you want them to do and you will be managing the platform in its entirety, then the answer is No.
Always feel free to talk to your implementation team leader if you aren't sure about this fundamental question in your implementation. They will be able to help you figure it out, as this is an area that you need to have clear before you begin configuring.