Shared orgs and sub-orgs in IDMC

Shared orgs and sub-orgs

Informatica Data Management Cloud (IDMC) uses the concept of an organization (an "org") as the highest-level container for objects, which include assets, projects, and connections. Orgs also contain a unique set of users and user groups. When on-boarding to IDMC, a decision must be made on whether to use the existing org for UW-Madison or use a new parent org with sub-orgs.

The purpose of this document is to help prepare for this decision.

Organizational hierarchy

IDMC has a hierarchy structure to ensure separation between teams and departments.

Parent orgs

A parent org is the highest-level concept in IDMC. A parent org can contain one-to-many sub-orgs and user groups.

Sub-orgs

A sub-org is functionally equivalent to a parent org, except that some aspects are inherited from the parent org. For example, a sub-org inherits licenses and connectors from the parent org. Parent org secure agent groups can also be shared to sub-orgs.

Integrations can be monitored from the parent org across all sub-orgs, providing operational information for all environments in a single view.

A sub-org cannot contain a sub-org. A sub-org can be created from within a parent org, or an existing org can be linked to a parent org to convert it into a sub-org.

User groups

A user group allows further separation and isolation within an org. When fine-grained authorization is needed within an org, a user group can be applied to objects (e.g., assets, connections, secure agents) to limit access to a subset of org users.

If no user group permissions are applied to an object, everyone within the org can access it.

User groups cannot contain other user groups.

Options

Use the shared org

This is the most commonly used option, and is strongly recommended if there is no specific need for a new org. For example, DCS, Admissions, SMPH, and DoIT-AIS all use the same org, sharing the development environment.

User groups and asset permissions are used to maintain security between groups. For more information, see Set up asset permissions in shared IDMC environment.

There is no extra cost to go this route, but there are some drawbacks to consider:

• User group permissions are not applied by default. Users must remember to apply user group permissions to their project or assets. If they do not, any user within the org can view, edit, or delete those assets.
• Connections and projects are visible in the list of all connections and projects, even if those objects have user group permissions applied. As a result, you will see other departments' projects and connections when browsing in the user interface or when selecting a connection from drop down menus. To help distinguish your objects from those of other teams, we recommend name-spacing them. See the Set up asset permissions in shared IDMC environment for more information.
• There are only two parent orgs: one for Test and one for Production. If more nuanced development environments (e.g., dev, QA, staging) are needed, this can represent a drawback. Objects can be named or organized to indicate a specific environment (e.g., dev-mapping, dev-project), but representing multiple development environments in a single org is not recommended. For recommendations on how to use the default Test and Production orgs, see the Working in multiple IDMC organizations.

Use a sub-org

A sub-org is functionally equivalent to a parent org, except that some aspects are inherited from the parent org. For example, a sub-org inherits licenses and connectors from the parent org. Currently, the DAPIR group is provisioned in this way (formerly named ODMAS).

• Parent org secure agent groups can also be shared to sub-orgs.
• A sub-org cannot contain a sub-org. A sub-org can be created from within a parent org, or an existing org can be linked to a parent org to convert it into a sub-org.

Unlike using the shared org, the sub-org approach has additional financial costs. Depending on your needs, the Integration Platform Team may be able to help cover the extra cost. Please contact us if this is something you would like to explore.

Here are some recommendations for when to use a sub-org:

• Sub-orgs can be used to isolate different environments such as test, qa, or prod.
• If your integration requires more than a few integration assets and connections, a sub-org may be a better fit.
• If fine-grained authorization is needed within a sub-org, a user group can be applied to objects (e.g., assets, connections, secure agents) to limit access to a subset of sub-org users.