Organizing and sharing connections

Folder patterns for Integration Service connections in Orchestrator, and how Personal Workspaces, folder roles, and subfolder access control who can use each connection.

Every Integration Service connection lives in an Orchestrator folder. How widely you share each connection is a design decision: one connection in a folder can serve every automation there, or a single automation can have a connection of its own.

There's no single right answer. The choice depends on:

• How sensitive the target system is
• What your security team requires
• How much administration you want to take on

This page describes five common folder patterns, when each one fits, and how folder permissions decide who can use a connection.

Personal and shared connections

Integration Service connections come in two kinds, and choosing between them is the first decision.

	Personal connection	Shared connection
Wo es existiert	A user's Personal Workspace (also called My Workspace) in Orchestrator	A team folder
Wer sie verwenden kann	Only that user	Everyone with access to the folder
Authenticates as	Generally, the user's own account in the target system	A service account

Empfehlung:

• Connections that authenticate through a personal account belong in a Personal Workspace.
• Every connection in a shared folder authenticates through a service account.

Avoid:

• A personal-account connection in a shared folder. Other people would run automations as that person, anyone with access to the folder could reach that person's private data in the target system, and everything that uses the connection breaks when that person changes roles or leaves.

With a service account, a shared connection outlives whoever set it up, and the audit trail points at an account that exists for that purpose rather than at the individual who created the connection.

Governing connectors in Personal Workspaces

Folder sharing isn't the control in a Personal Workspace, because the workspace already belongs to one person. Two other controls apply:

• Automation Ops policies decide which connectors users can create connections for. For example, a policy can allow productivity tools and block systems of record. Policies are deployed to tenants, groups, or users rather than to folders, so a connector disabled for a user is disabled in every folder, not only in their Personal Workspace. For more information, refer to Settings for Integration Service policies in the Automation Ops user guide.
• Folder roles decide where users can create connections. Withholding the Connections - Create permission in shared folders keeps personal connections in Personal Workspaces. For more information, refer to Enforcing user-level Integration Service connection governance in the Orchestrator user guide.

How folder access controls connections

The rest of this page covers shared connections: where they live, and who can reach them. Connections sit in folders, the same as assets, queues, and storage buckets. Access to them comes from the role a person holds in that folder.

What a folder role controls

A folder role sets what someone can do with the connections in that folder:

• Connections - View: use the connections to run automations, without changing them.
• Connections - Edit, Create, Delete: add connections, edit them (including changing the credentials or the authentication method), or remove them.

This lets a team have use-only access while the right to change connections stays with whoever owns them. For more information on folder roles, refer to Configuring access for accounts in the Orchestrator user guide.

What a folder role can't control

A role applies to every connection in the folder. There's no way to grant access to one connection and withhold another in the same folder: if a folder holds three connections and someone has View there, they can use all three.

Access flows down to subfolders

Access to a folder reaches everything beneath it. A user or group granted access to a folder can also use the connections in every subfolder under it, not only the connections in that folder itself.

A subfolder is therefore never more private than its parent. Placing a connection deeper in the tree doesn't hide it from anyone with access higher up.

Finance            ← Finance team granted here
  AP               ← the Finance team can use this folder's connections too
  FP&A             ← and this folder's

Plan the folder structure around this behavior. A connection that must stay out of reach of a group can't live anywhere underneath a folder that group has access to.

Choosing a pattern

The following table matches common situations to a pattern. Common folder patterns describes each pattern in detail.

Situation	Recommended pattern	Grund	Isolates each automation?
Development, testing, and production separation	Pattern 1: a shared connection per environment folder	Folder access already implies the trust level	No, relies on folder-level trust
Lower-sensitivity, high-reuse system	Pattern 2: a shared connection per folder	Simplicity outweighs the limited blast radius	No, relies on folder-level trust
Security policy requires per-automation credential isolation	Pattern 3: a dedicated connection in a dedicated folder, per automation	Folder access can't map a credential to one automation	Yes, but only while the automation has its folder to itself
Isolating departments on a shared provider	Pattern 4: a shared connection per department folder	Matches the isolation boundary you need	No, isolates by department, not by automation
Centralized credential ownership across teams	Pattern 5: a shared connection in a centrally governed folder	The goal is governance ownership, not finer access control	No, relies on folder-level trust

Wichtig:

If your security team requires that any credential's usage be traceable to a single automation, folder-level sharing doesn't meet that requirement on its own. Use Pattern 3.

Common folder patterns

Each pattern describes the situation it fits, the recommended setup, and the trade-off of the closest alternative.

Pattern 1: Environment separation

Use case: each environment (development, testing, and production) needs its own credentials for a provider, so an automation under development can never reach the production system.

Empfehlung:

• A separate folder per environment, each holding one connection.

Avoid:

• One connection across all three environments. A development automation could then reach production.

Alternative: a dedicated folder and connection per automation (Pattern 3). This works, but you manage far more folders and connections for no extra safety, because the environment folders already keep development away from production.

For how an automation picks up the right connection in each environment, refer to Configuring connections per environment.

Separate tenants per environment

Some organizations with mature automation programs use a separate tenant per environment instead, which gives better isolation than folders do. Connections can't cross a tenant boundary, so a development automation can't reach production at all.

With a tenant per environment, this pattern no longer applies inside a tenant: each tenant already holds one environment, so folders are free to follow departments and teams (Pattern 4). The trade-offs are:

• More tenants to administer.
• Promoting an automation means moving it between tenants rather than between folders.

On a single tenant, folders are the way to separate environments, and the lighter of the two options.

Pattern 2: Shared connections for lower-sensitivity systems

Use case: multiple automations need to reach the same non-sensitive system, such as a reporting data warehouse, and the organization wants to keep the number of credentials it maintains and rotates to a minimum.

Empfehlung:

• One connection in a shared folder, used by every automation in that folder.

Avoid:

• A separate folder and connection for each automation. This adds credentials to rotate and maintain without reducing any real risk.

Alternative: isolating a specific automation in its own folder (the Pattern 3 approach) tightens isolation, at the cost of more folders and connections for a system that likely doesn't need that protection. This is reasonable only if you prefer consistent per-automation hygiene everywhere.

Pattern 3: Dedicated connections per automation for sensitive systems

Use case: your security policy requires that each credential set be traceable to one automation, and revocable for that one automation alone. This requirement is common for SAP, Salesforce, and other systems of record.

Empfehlung:

• A dedicated folder for the automation, holding one connection that nothing else uses.
• The folder at the top level, or nested only under folders that nobody else has access to.

Avoid:

• A second automation in the same folder.
• The folder under a team or department folder for tidiness. Access flows downwards, so everyone with access to the parent folder can use the connection underneath it.
• A shared connection for this automation. Anyone with View in that folder can use it, so you can't tell which automation used the credential.

There's no way to tie a connection to a single automation directly. The folder structure provides the guarantee: one automation per folder, and nobody with access to a folder above it. If either condition breaks, the guarantee is gone.

Pattern 4: Business-unit isolation on a shared provider

Use case: two departments use the same system, for example Finance and HR on the same ERP product with an instance each, and neither department should be able to reach the other's data.

Empfehlung:

• A folder with its own connection for each department.
• The same pattern again for separation inside a department: a folder and connection per sub-team, with access granted on each sub-team folder rather than on the department folder. A grant on the department folder reaches every sub-team underneath it, and would undo the separation.

Avoid:

• One connection for the whole company. Every department's automations could then reach every other department's data.
• Nesting deeper than your teams need. Departments × sub-teams × environments multiplies folders quickly, and every added level is another connection to rotate.

Alternative: if you also need to know which automation used a credential, not only which department, give that automation its own folder (Pattern 3). This means more folders and connections to track, so reserve it for cases where an audit calls for it.

Pattern 5: Centrally governed shared connections

Use case: multiple teams need to reach the same system, and the organization wants one accountable owner for those credentials (provisioning, rotation, and audit) instead of each team managing its own.

Empfehlung:

• The connection in a folder the central team owns, with other teams granted access to that folder.
• View for those teams, so they can use the connection but not change it, with Edit kept by the owning team.

Avoid:

• A company-wide connection anyone can reach. Nobody then owns rotation.

Alternative: the central team can isolate specific automations in their own folders (the Pattern 3 approach) instead of sharing one connection. This keeps the same rotation process and adds per-automation traceability, but gives the central team more folders and connections to manage, trading away some of the simplicity that makes this pattern attractive.

Wichtig:

This pattern's only structural advantage over a single tenant-wide connection is that access to the folder is granted selectively and can be revoked. If the folder ends up granted to nearly everyone, the two become equivalent in practice, so keep the grant list narrow or the governance is nominal.

Why a tenant-wide connection per provider isn't a pattern

The patterns on this page reduce to two models: a shared folder connection (Patterns 1, 2, 4, and 5, where the mechanism is the same and only the reason for sharing differs) and a dedicated per-automation connection (Pattern 3). A third option is sometimes proposed: a single tenant-wide connection per provider, such as one SAP connection and one Salesforce connection used by every automation regardless of folder.

A tenant-wide connection per provider is a weaker version of Pattern 5. The topology is the same: one connection serves multiple teams and automations, with no way to trace usage to a particular consumer. A centrally governed connection adds two things a tenant-wide one lacks:

• Teams must be explicitly granted access to the folder, and that access can be revoked.
• The folder can hold multiple connections, including multiple instances of the same provider (for example, three regional SAP instances), which a single per-provider connection can't represent.

Accountable ownership isn't a real difference. Nothing prevents an organization from assigning an owner to a tenant-wide connection; that's an operating practice, not a property of the scoping model.

The distinction rests entirely on a selective grant boundary. Pattern 5 is the right way to express this need, while a tenant-wide connection per provider gives up the boundary for nothing in return.

Combining patterns

A single folder structure can combine several patterns, for example a shared connection for a low-sensitivity reporting system alongside dedicated per-automation connections for a sensitive ERP integration. The pattern is a choice per system, based on its sensitivity and your security requirements, rather than one approach for every connection. The following examples show common combinations.

Departments, sub-teams, and environments

Departments need separate connections, sub-teams within each department need their own too, and development, testing, and production must stay apart. This isn't a new pattern: it's Pattern 4 applied twice, with Pattern 1 on top and environment at the outermost level.

Prod
  Finance
    AP           → connection
    FP&A         → connection
  HR
    Payroll      → connection
    Recruiting   → connection
Test
  (same shape)
Dev
  (same shape)

Environment at the top level

A mistake that crosses from development into production is worse than one that crosses from Finance into HR, so the environment split should be the most visible one. Environment is also the axis automations move along: promoting an automation from test to production is routine, while moving one from Finance to HR isn't. With environment at the top, promotion is a move between parallel trees rather than a change deep inside one.

Environments as separate tenants

If you separate environments by tenant rather than by folder, the top level disappears and each tenant holds only the department and sub-team levels. It's worth confirming this before building three copies of the same structure.

Sharing connections where credentials match

Sub-teams don't always need separate credentials. If AP and FP&A both use the same Finance ERP account, they can share a department-level connection and still have their own folders for their automations. That cuts the number of connections by two thirds and keeps the same structure. Separate connections are only needed where the credentials or the target instances differ.

Grants at the lowest folder

This structure separates AP from FP&A only if nobody has access at the Finance level. Access flows downwards, so a grant on Finance reaches both sub-teams and their connections. Finance works purely as a container, with the grants placed on AP and FP&A themselves.

Shared tools and sensitive systems side by side

In a typical tenant, different systems get different treatment within the same folder structure.

Shared Services (owned by the Center of Excellence)
  Email connection          → View granted to the teams that need it
  Teams connection          → View granted to the teams that need it
  Document store connection → View granted to the teams that need it

Finance
  Reporting                 → one shared connection

SAP — Invoice posting       → its own folder, its own connection
SAP — Payment run           → its own folder, its own connection

This example combines three patterns: Pattern 5 for the shared tools, Pattern 2 for reporting, and Pattern 3 for the two SAP automations.

The SAP folders sit at the top level, not under Finance. If they were nested under Finance, everyone with access to Finance could use their connections and the isolation would be lost. Folder names that identify the owner keep ownership obvious despite the flat placement.

One automation team serving multiple customers

An automation team runs the same processes for multiple end customers.

Customer A
  Connection to Customer A's systems
Customer B
  Connection to Customer B's systems
Customer C
  Connection to Customer C's systems

This is Pattern 4 with customers in place of departments. The same automation is deployed into each folder, and each folder has its own credentials. This setup calls for strict treatment: one customer's credentials reaching another customer's data is a contractual problem, not only an internal one.

Data residency by region

Data residency is decided at tenant level: a tenant in each region, with folders inside each tenant for everything else.

EU tenant  (hosted in the EU)
  Prod → NetSuite EU production connection
  Test → NetSuite EU test connection

US tenant  (hosted in the US)
  Prod → NetSuite US production connection
  Test → NetSuite US test connection

A connection can't cross a tenant boundary, so EU data is out of reach from the US tenant regardless of how folder roles are set up.

Inside each tenant, environment goes at the top level, with access granted there. Users who must never touch production get access under Test and nothing above it.

This follows the same idea as the tenant-per-environment option in Pattern 1: when a boundary really matters, a tenant enforces it, while a folder only organizes it.