Departmental Sub-Org Setup
Your company has multiple independent departments. Each have their own users and administrative needs. Some users may work for multiple departments. In this document we discuss 4 setup techniques in Agilicus AnyX, and the pro/con of each.
All 4 methods achieve the same objective, and are equally secure.
Resources and connectors cannot be shared across Orgs, meaning if you have a single Resource you want multiple departments to use, you must either use a hierarchical model (where all users needing the share resource are in the same org, and optionally in a child), or, you must dual-configure the resource (e.g. 2 connectors lead to it, and, the resource is created in each Org where users might require it).
Method #1: Sibling
In this model, there are 3 Orgs created. The parent (“My Company”) has only the global admin(s): it has no resources, no connectors. There is 1 (or more) global admin users in the parent org, but no end-users, no departmental admins.
The end users will all use the same profile URL (https://profile.__MYDOMAIN__). They will each see a custom view, only their resources. Users in both orgs will see navigation folders.
This method is best suited to a non-overlapping set of users and resources, perhaps split geographically or by division.
Method #2: Parent-Child
In this model there are 2 Orgs created. The parent (“My Company”) has all of the common users and resources (as well as global admins). A ‘Child’ org is setup for each team with its own admin/resource needs.
The end users will all use the same profile URL (https://profile.__MYDOMAIN__). They will each see a custom view, only their resources. Users in both orgs will see navigation folders.
This method is best suited where most users have something shared, and some users have things not shared.
Method #3: Peer
In this model, 2 top-level Orgs are created. There is nothing shared between them.
In this model, end users each have their own profile URL (https://profile.team-1.__MYDOMAIN__ and https://profile.team-2.__MYDOMAIN__). There is no ability to have shared resources: if a resource is needed by both teams, it must have 2 connectors setup, and, be configured in each org.
This peer model facilitates invoicing to separate corporations (e.g. different tax numbers, addresses).
Method #4: 1 Org with Permission Management
In this model there is only 1 global admin, no departmental admins. User permission is managed to ensure that each user gets access to only their department’s resources.
This model is more work to administer, and has some risks of mis-configuration. However, it is simpler to operate, simpler to audit.
If you have a single org with all users in it, and wish to migrate to one of these models, consider the following steps:
- Create new orgs as needed (except for model #4).
- Create new connectors in new orgs
- Create new resources in new orgs
- Create user groups in new orgs
- Create users into new orgs
- Delete users from orgs they no longer need.
To create a new org, use Organisation/New menu (Model #1/Model #2). Give this a name of e.g. the department.
For Model #3 (Peer), you would need to run through the Signup process again.
For Model #4, Orgs are not used and can be ignored.
Consider who will have administrative abilities in each of the new Orgs. You can add them directly to the administrative permissions as at the right, or, create a group (e.g. ‘org-admins’), add them to that, and and then add the org-admins to the administrative system group.