Admin Settings — Confluent Self-Service Docs

Overview

Admin → Settings is where a business-unit admin shapes how the portal behaves for their team: what developers may change, how resource names are built, and — for landing-zone admins — the Tableflow and Flink guardrails. It is the only place where these values are edited; everything else about a business unit (credentials, cluster wiring, Entra ID group mappings) is managed by the Platform Team.

The page follows your context: select a business unit and stage in the sidebar and the page shows the settings for exactly that pair. A change is saved straight to the platform's configuration store and takes effect across the portal within seconds — no restart, no ticket.

Who can open it, who can change what

The Settings entry appears in the sidebar for Admins, Super Admins and platform admins. Developers and viewers never see it. Which rows you can edit depends on how far the setting reaches:

Section	Applies to	Who can change it
Developer permissions	This business unit, this stage only	Admin of this business unit on this stage, Super Admin, platform admin
Resource naming	This business unit, all stages	Admin of this business unit, Super Admin, platform admin
Tableflow, Flink	The whole landing zone — every business unit sharing it	Super Admin, platform admin only

Rows you cannot change are shown but locked; hovering the control tells you which role is needed. Since roles are resolved per stage, an admin on dev who is only a developer on run can change the developer permissions for dev but not for run.

Developer permissions

Three switches decide what a Developer may create, update or delete in this business unit and stage. All three are off by default, so a freshly onboarded stage is read-only for developers until an admin opens it up. Admins, Super Admins and platform admins are never limited by these switches.

Allow Modify Resources

Covers the data plane: topics, connectors, schemas, Flink statements and topic actions. Tableflow is not covered: enabling, editing or disabling it always needs an Admin. When it is off, the Topics, Connectors and Schemas pages show the "Resource changes are disabled for this environment" banner, create / edit / delete controls are disabled, and the API answers 403 Forbidden to any change. Typically left off on run.

Allow Manage Service Accounts

Lets developers create, update and delete service accounts and their API keys (including key rotation). Independent of Allow Modify Resources: a team can be free to manage topics while service accounts stay with the admins, or the other way round.

Allow Manage Identity Pools

Lets developers create, update and delete identity pools. Also independent of the other two switches.

Visible to API clients too

Every list endpoint returns allow_modify_resources; the service-account list adds allow_manage_service_accounts and the identity-pool list allow_manage_identity_pools. A client can read them to decide whether to offer a change before trying it.

Resource naming

Every resource a team creates — topics, connectors, service accounts, compute pools, the output of a topic action — gets its full name from the Resources Naming Template. The user types only the last part; the portal fills in the rest and shows a live preview under the field. This section applies to all stages of the business unit.

Resources Naming Template

Built from the placeholders {landing_zone}, {business_unit}, {stage} and {id} (the part the user types). {id} is mandatory. When nothing is set, the portal uses {landing_zone}-{business_unit}-{stage}-{id} on a shared cluster whose landing zone is not the business unit itself, and {business_unit}-{stage}-{id} otherwise.

On a shared cluster the prefix in front of {id} is what keeps one team's resources apart from another's, so the page refuses to save a template that does not contain both {business_unit} and {stage} before {id}. Dedicated clusters accept any template with an {id}.

Normalize Resource Identifier

On by default. Lowercases the part the user types and replaces dots and underscores with hyphens before it is put into the template, so Orders_V2 becomes orders-v2. Turn it off only if your team relies on mixed case or underscores in names.

Changing the template does not rename anything

Existing resources keep their names. On a shared cluster the portal lists a team's resources by their prefix, so resources created under an old template may drop out of view. Agree a template early and leave it alone.

Landing-zone guardrails

The last two sections are shared by every business unit in the landing zone, which is why only Super Admins and platform admins may change them.

Tableflow — Provider Integration ID

The Confluent provider integration (cspi-…) that lets Tableflow write into your Azure storage. Set once by the Platform Team when Tableflow is enabled for the environment; the Tableflow wizard uses it automatically.

Flink

Flink Max CFU Cap (default 10) — the largest max-CFU a compute pool may be created or resized to. Keeps a single team from reserving the landing zone's budget.
Flink Default CFU (default 5) — the size pre-selected on the create-pool form. Both CFU values must be one of Confluent's increments (5, 10, 20, 30, 40, 50), and the default cannot exceed the cap.
Flink Workspace Idle Timeout (default 15 minutes, 1–1440) — how long an ad-hoc SQL Workspace query may sit idle before the platform stops it to free CFUs. Deployed statements are never touched. See What it costs.

Saving changes

Change one or more rows — each edited row is marked Unsaved and the Save changes button shows how many are pending. Reset discards them all.
A CFU that is not an increment, an out-of-range timeout or a provider integration ID without the cspi- prefix is flagged under the field and blocks saving. A naming template is checked when you save: one without {id}, or on a shared cluster one missing {business_unit} or {stage} before {id}, is rejected with the reason.
Click Save changes. Rows are saved one by one; the page reloads the effective values when it is done, and every portal instance picks the change up immediately.

Every change is audited

Each save — and each refused attempt — is written to the audit log with the old and new value and who made it. Platform admins can review it under Admin → Audit Log.

When a save is refused as "shadowed"

Occasionally a save is refused because the same setting is also defined at a more specific level in the configuration store, which would silently override what you saved. The portal refuses rather than let that happen. Contact the Platform Team with the setting name and the label from the message; they will resolve it in the configuration store.