Platform Object Model

This article discusses the types of objects that exist within a Flowgear Tenant and their relationnships with each other.

Scope map

Tenant
├── Accounts
│   ├── Subscriptions ── allocate features and capacity to Sites
│   ├── Account users and permissions
│   └── Published Apps ── assigned to Sites
├── Tenant-wide administrators and resources
└── Sites
    ├── Environments
    ├── Site users and permissions
    ├── Workflows and Workflow folders
    ├── Connections and Connection folders
    ├── API Keys and API Key folders
    ├── local execution resources
    └── configuration and operational records

The diagram shows scope and relationships, not automatic permission inheritance. A user needs the relevant global, Account, Site, and, when enabled, Environment access for each action.

Tenant

The Tenant is the top-level identity, sign-in, infrastructure, and administration context. Tenant-level views include Accounts, global administrators, Security Groups, Cloud Clusters, platform logs, published Nodes, and App management.

Tenant access does not mean every user can administer every object. Security Group assignments grant permissions at global, Account, or Site scope.

Account and Subscription

An Account owns subscriptions and published Apps. A subscription defines a product, effective dates, features, and limits, then allocates some or all of that capacity to Sites.

The Account is a commercial and ownership boundary. It does not replace the Site as the container for integration content. Assigning a Site to a subscription makes licensed features and capacity available to that Site.

Site

A Site is the main workspace and permission scope for a related set of solutions. Workflow and Connection identities, folders, API Keys, Site users, configuration, logs, relationships, and audit activity carry Site context.

Use separate Sites when solutions have different owners, access rules, subscription allocations, or operational responsibilities. Use Environments when the same Site content needs separate lifecycle stages and configuration.

Environment

An Environment is an ordered development, publish, runtime, configuration, routing, and optional permission boundary inside a Site. It is not a smaller Site and does not duplicate every Site object.

The following identities are Site-scoped but have Environment-specific values or state:

Site-scoped identity	Environment-specific state
Workflow	Published revision, runtime context, logs, and metrics
Connection	Endpoints, credentials, certificates, and other Property values
API Key	One immutable target Environment and its protected token storage where applicable
Site configuration	Configuration value for the Environment
Key/value entry	Value partitioned by Site and Environment

Environment hostname selects the context for inbound HTTP and MCP requests. Release Management moves Workflow revisions through ranked Environments. Sub-Workflows run in the caller's active Environment.

Site-scoped objects

Workflows, Connections, and API Keys have stable Site-scoped IDs. Folders organize these objects in separate Site-scoped trees. Moving or renaming an object changes its presentation and path, not the stable ID used by references and tools.

Local execution resources provide placement for Workflows that need access to private systems. Their configuration and placement rules depend on the Workflow runtime. See v1 Runtime and v2 Runtime.

Published Apps differ from most integration objects: an Account owns the App package, and administrators assign that App to Sites. The App invokes Site Workflows through the selected Environment and the configured authorization model.

Names and IDs

Names are editable labels for people. Keys or IDs are stable strings used in Console routes, YAML, API payloads, relationships, and agent tools.

Do not invent an ID from an object's name. Discover the object, select it in Console, or use a supported tool to obtain its key. When an instruction asks for a Workflow, Connection, folder, Cluster, Site, or Environment key, use the exact stored value.

Permissions

Security Groups contain permissions with global, Account, or Site scope. Users are assigned to those groups for a particular scope object. Site assignments can additionally carry Environment IDs when Environment-scoped permissions are enabled.

Environment access supplements Site permissions; it does not grant a missing permission. Object-level authorization, such as API Key Workflow/user assignments or App Site assignment, is another separate check.