This article is intended for IT Glue account administrators. When thinking about how to use sub-organizations, there are a few points to consider. Let's start by defining the key terms and then explaining how sub-organizations can be useful.
- Represent the top-level structure of clients and can have as many locations and sub-organizations as desired.
- Each asset or document can belong to only one organization and can be viewed by users who have access to that organization depending on the item's permissions.
- Used to segment an organization so that there is a parent and one or more children sub-organizations. They can be used to separate locations or departments of the parent as needed.
- Assets and documents can belong to the sub-organization (and not the parent) and can be viewed by users with access to that sub-organization depending on the item's permissions.
- Sub-organizations do not inherit any permissions from their parent.
- Represent physical locations and addresses where the client's users may perform work.
- Each asset or document can be shown to exist in a particular location only if a relationship is created (tagging).
When to use sub-organizations
With PSA syncing, IT Glue will automatically create sub-organizations if our sync logic detects parent-child relations coming from the PSA. A typical use for these children sub-organizations in your PSA is to bill to separate entities from the same client. In IT Glue, sub-organizations do not have a pre-defined use, and for your clients that are billed as one entity, organizations and locations will often be enough to match the desired structure.
However, as fully separate entities, sub-organizations may make it easier to manage location-based documentation for certain clients. An example of this is if the infrastructure used at one of the client's locations doesn't rely on the infrastructure of the parent organization. In this type of model, the documentation can be structured in a way that will match better with client infrastructure and with each location's documentation needs.
The ability to have defined access permissions is a secondary benefit of sub-organizations. In another example, permissions can be managed such that an overarching authoritative user (client's CEO) can be granted permissions to the parent and all child sub-organizations, and conversely, a user (project leader) can be granted access to just a sub-organization and not to the parent.
Navigating to sub-organizations
When viewing an organization's home page, you can see its sub-organizations by scrolling to the bottom of the screen. You can also search for a sub-organization by its name and navigate to it directly instead of going to the parent organization.
When you view a sub-organization, you'll see the top-level organization in the breadcrumbs navigation near the top of the screen.
For information about creating sub-organizations, see the following article: