Platform Configuration
How an organization sets up shared labels, shared values, and outbound event connections once for everyone.
Everything in this cluster is organization-wide configuration — the tags your organization defines, the values it stores, and the events it sends to other systems — so what you can view and change depends on the role permissions you have been granted. The access model is documented in one place: Access & Permissions.
Purpose
Your organization is a single tenant on Opal — the top-level container that represents your company and holds its members, teams, roles, resources, and organization-wide settings. Platform Configuration is the part of it that deals with how the platform itself is set up for everyone: the shared labels, the shared values, and the connections to the systems your organization already runs.
Three configuration options sit here, and each answers a different question:
- How do we keep track of what we have? — resource tags, the labels your organization defines and applies to its resources.
- Where do our shared values live? — variables, the tokens, credentials, and configuration values stored once and referenced wherever they are needed.
- How do other systems find out what happened? — webhooks, which subscribe to platform events and send them outward.
What they have in common is that they are set up once, centrally, rather than by each team. Tags and webhooks are managed in Organization Settings, the central area where an organization's profile and preferences, security, membership, teams and roles, billing, and credits are administered; variables are managed in the Variables section. In each case, one decision serves the whole organization instead of every team improvising its own.
There is a reason to configure these early rather than later. Opal connects to the applications an organization already uses and can push platform events out to them, and governance in Opal is treated as a foundational, cross-cutting layer rather than something added after deployment. Platform Configuration is where both of those become concrete: a small number of shared conventions and stored values that everything built afterwards can rely on.
This page is the map. It introduces the three pages in this cluster, explains how they fit together, and tells you where to start.
In This Section
- Resource Tags — How to define organization-wide tags, choose which resource types each one applies to, apply them as resources are built, and filter to everything carrying a tag. Resource Tags
- Variables — How to store tokens, credentials, and configuration values once — each with a key, a type of text or secret, and a value — and reference them when configuring MCP Connections, Tool Definitions, and Webhooks. Variables
- Webhooks — How to create webhooks that subscribe to platform events and send them to external systems, and how to use the request log to see what was sent and re-attempt a request. Webhooks
Key Concepts
Three options, three separate jobs. Tags classify the things your organization builds. Variables hold the values its configuration depends on. Webhooks tell other systems what happened. They are grouped together because they are all organization-wide setup, not because they do the same thing — so treat them as three short decisions rather than one large one.
Configured once, used by everyone. A resource tag is defined at organization level, so teams classify resources with the same shared vocabulary instead of inventing personal labels. A variable is stored once, so every configuration that needs the value refers to the same entry. A webhook is created centrally, because it sends organization data outward. Each of these gets its value from being shared.
They build on each other. Variables are referenced when configuring MCP Connections, Tool Definitions, and Webhooks — which is why a webhook that authenticates to an external service should reference a stored variable rather than hold a copy of the credential. Tags then keep the growing set of resources organized and navigable, so oversight stays practical as the library expands.
Configuration is governed like anything else in Opal. Variables carry their own resource-level permissions, version tracking, and a Linked Resources panel that shows where a value is used before you change it. Webhooks keep a request log of what was sent, with the option to re-attempt a request. Resource tags are one of Opal's governance controls in their own right, alongside permissions, versioning, the activity log, linked resources, and the optional publishing workflow. Not every resource supports every control, so check the resource itself for what is available. See Governance.
Configuration is not access. Applying a tag, storing a variable, or creating a webhook does not decide who can do what. That comes from your organization's plan, the role permissions granted to each member or team, and the permissions on each individual resource — documented once in Access & Permissions.
Sending events out and keeping a record are different things. A webhook pushes platform events to the systems that need to act on them. The organization's own traceable account of activity is the audit log, covered by Audit Log.
Short definitions of the terms used here are in one place: Glossary.
Where to Start
If you are setting up an organization, start with Resource Tags. It has no prerequisites, it is the decision that gets harder to retrofit as the number of resources grows, and agreeing a small set of tags early is what makes the rest easy to keep track of.
From there, work through the cluster in this order. They are three separate decisions rather than one — only webhooks depend on an earlier step, because a webhook references the variables you have stored:
- Resource Tags — agree the labels your organization will classify resources with, and set which resource types each one applies to. Resource Tags
- Variables — store the tokens, credentials, and configuration values your integrations need, so nobody pastes a raw credential into a configuration. Variables
- Webhooks — subscribe to the platform events your other systems should hear about, referencing the variables you stored in the previous step. Webhooks
If you are here for one thing — adding a tag, rotating a credential, checking why an external system did not receive an event — go straight to the page that covers it.
For the rest of organization-level administration — the organization's profile and preferences, members and access, billing and credits, and governance — start from Organization.