Does support need builder access to help me?

Configuration and diagnostics are platform concerns and live in the builder plane. Reaching into a specific organization's records is a different question, and it should be a deliberate, recorded action rather than an ambient capability.

Is this the same as a control plane and a data plane?

It is the same idea applied to application privilege rather than infrastructure: one plane defines how the system behaves, the other operates a business inside it.

Can builder configuration change my organization's data?

Configuration changes definitions — what actions exist, how a workflow is shaped. Anything that writes to an organization's records is a runtime operation and carries the same tenancy and audit requirements as any other write.

Knowledge · Architecture

Builder Plane vs Runtime Plane

The plane that configures a system and the plane that runs a business are different security domains. Why they should never share a permission model.

What is the difference between a builder plane and a runtime plane?

The runtime plane is where a business operates its own records: leads, jobs, invoices, crews. The builder plane is where the platform itself is configured: capability catalogues, workflow definitions, diagnostics. They are separate security domains, and a runtime role should never be able to reach into the builder plane.

Key takeaways

Configuring the system and using the system are different privileges.
A tenant's most senior role is still a runtime role.
Builder access should be a platform-level check, not an organization role.
Builder surfaces should be invisible and unreachable from tenant interfaces.
Platform diagnostics are not customer data and must not leak into tenant views.

Why the tenant owner is not a platform administrator

An organization owner holds the highest authority over their own business's records, and none over the platform's definitions. Collapsing the two produces the familiar super-administrator problem, where the only way to fix a platform issue is to hand someone unrestricted reach across every tenant.

What belongs on each side

Runtime: customers, leads, estimates, jobs, invoices, crews, messages, the organization's own settings and its own users.
Builder: capability catalogues, workflow and playbook definitions, platform diagnostics, code and policy coverage checks.
Neither: raw production credentials, which belong in a managed secret store scoped to the functions that need them.

Isolation means invisible, not merely denied

A builder surface that is denied but discoverable still tells every tenant that a privileged interface exists and invites probing. Builder routes should not appear in tenant navigation, should not resolve for tenant identities, and should be gated by a platform-level check that no organization role can satisfy.

Where URBLD fits

URBLD reserves its builder role for the platform owner and isolates it from tenant interfaces. Builder-only surfaces — the capability catalogue, workflow playbook editing, policy-coverage and code-quality diagnostics — are gated by a platform-level check evaluated in security-definer database functions, distinct from the four organization roles. No organization role, including owner, grants builder access.

Security at URBLD Registered action execution

FAQ

Frequently Asked Questions

Straight answers about how URBLD runs the business end-to-end.

Related knowledge

Owner Zone and privileged boundaries

Roles vs capabilities