Copy page

Data Operations

Organization resource sharing

Share resources you own with the sub-orgs in your organization, so they can use them in their own pipelines without duplicating configuration or handling secrets directly.

Overview

Resource sharing lets a top-level organization make selected resources available to its sub-orgs. Key concepts:

• Sharing flows one way, from an organization to its sub-orgs: a top-level organization shares resources with its sub-orgs (child organizations). Sub-orgs can use a shared resource but cannot share it onward, and a resource that was shared with you cannot be re-shared.
• Five kinds of resource are shareable: inputs, outputs, transforms, enrichments, and secrets.
• Shared resources are read-only to the receiving sub-org: a sub-org can use a shared resource in its pipelines but cannot edit or delete it. Only the owning organization can change it.
• A resource that is in use is protected: you cannot stop sharing a resource with a sub-org while that sub-org still has something using it.

Note: When several sub-orgs use a shared input in their own pipelines, each pipeline runs the input independently. For most inputs each pipeline receives its own full copy of the data, but pipelines reading the same SQS queue split its messages between them. See Using One Input in Multiple Pipelines before sharing a queue-based input.

What you can share

You can share the four component types (inputs, outputs, transforms, and enrichments) as well as secrets. Sharing a secret lets a sub-org reference a credential you manage without ever seeing its value.

Only a top-level organization can share resources out. Sub-orgs cannot share, and a resource shared with your organization cannot be shared onward to another organization.

Sharing a resource

There are two ways to share. A resource appears on the Resource Sharing page only after it has been shared at least once, so the first share always starts from the resource itself.

Quick share from a resource

Every shareable resource has a Share action, both in the Actions column of its list page and at the top of its detail page.

1. Open an input, output, transform, enrichment, or secret, or find it in its list.
2. Choose Share from its actions.
3. In the dialog, check the sub-orgs that should have access. Sub-orgs already sharing the resource are marked Shared, and sub-orgs with something using it are marked In use.
4. Click Confirm to apply.

From the Resource Sharing page

The Resource Sharing page (in the sidebar) lists everything your organization has shared. Select a row to open that resource's sharing detail page.

1. On the detail page, open the Share with sub-orgs tab. It opens read-only, listing the sub-orgs that currently have access.
2. Click Edit to change access. Check a sub-org to share with it, or uncheck a sub-org to revoke its access.
3. A summary describes your pending changes before you commit them (for example, "Sharing with 2 sub-orgs and revoking access from 1 sub-org").
4. Click Save to apply the changes.

Note: Use Deselect unused to quickly clear every selected sub-org that is not actively using the resource.

Automatically sharing with new sub-orgs

Each resource has an Automatically share with sub-orgs added later toggle. When it is on, any sub-org created in your organization after that point automatically gets access to the resource. When it is off, new sub-orgs are not shared with automatically, and you share with each sub-org explicitly.

In the read-only view this shows as a status line: "Automatically shares with new sub-orgs" or "New sub-orgs are not shared automatically."

Unsharing and resources in use

To stop sharing a resource with a sub-org, open its Share with sub-orgs tab, click Edit, uncheck the sub-org, and Save.

Note: You cannot unshare a resource from a sub-org while that sub-org is still using it. The attempt fails with "Cannot unshare a resource that a sub-org is currently using." Remove the use first, then unshare.

The Resources in use tab lists the sub-orgs currently using the resource so you can see what is blocking an unshare. A shared secret is used by a sub-org's components (inputs, outputs, and enrichments); a shared component is used by a sub-org's pipelines.

Working with shared resources as a sub-org

When a resource is shared with your sub-org, it appears in your resource lists with a Shared with this org badge, and it is read-only: you can use it but not change it. Sub-orgs cannot share resources themselves; only the parent organization that owns a resource can share it.

In a pipeline, any node that references a shared resource shows a shared badge with a tooltip, so you can tell at a glance when a node depends on a resource you do not own. The node details panel lists the shared resources the node references.

On the owning side, resources your organization has shared show a Shared badge with a Manage sharing link that takes you to the resource's sharing detail page.

Common scenarios

The patterns below combine the features above into complete workflows.

Centrally managed credentials

Your organization owns the credentials for a common destination, such as a Splunk HEC token, and several sub-orgs need to deliver events with it. Instead of handing the token to each sub-org:

1. Create the secret in your top-level organization.
2. Share it with the sub-orgs that need it, using either flow from Sharing a resource.
3. Each sub-org references the shared secret when configuring its components. It appears in their secret selectors with a shared badge, and its value is never exposed to them.

When the token rotates, update the secret once in the owning organization. Every sub-org's components pick up the new value, with no coordination required.

A standard destination and schema for every sub-org

You want every sub-org's data to land in one governed destination, in one schema, no matter which sub-org built the pipeline:

1. Configure the output (for example, an S3 or Snowflake output) in your top-level organization, along with the transform that normalizes records into your standard schema.
2. Share both with all of your sub-orgs.
3. Sub-orgs attach the shared output and transform to their own pipelines. Because shared resources are read-only to them, no sub-org can quietly change the destination or drift the schema.

Configuration changes, such as a new bucket prefix or an updated mapping, are made once by the owning organization and apply everywhere the resource is used.

Day-one access for new sub-orgs

Your organization creates sub-orgs regularly and wants each one productive immediately, without a hand-off checklist:

1. Decide on the baseline resources every sub-org should have: typically a destination output, a normalization transform, and the secrets they depend on.
2. On each of those resources, enable Automatically share with sub-orgs added later.
3. When a new sub-org is created, the baseline resources appear in its lists right away, ready to use in its first pipeline. No explicit share step is required.

Note: The toggle only applies to sub-orgs created after it is switched on. Share with existing sub-orgs explicitly.

Winding down access safely

A sub-org is being retired, or a resource is being replaced, and you want to revoke access without breaking pipelines that still depend on it:

1. Open the resource's sharing detail page and check the Resources in use tab to see which sub-orgs still use it.
2. In the Share with sub-orgs tab, click Edit, then use Deselect unused to clear every sub-org that has nothing using the resource.
3. For sub-orgs still using it, have the dependent pipelines or components removed first, since an unshare is blocked while the resource is in use. Then uncheck those sub-orgs and Save.

Working in this order means you never pull a resource out from under a running pipeline.