Access control

OBIC controls access at three levels: which objects a role can touch, which rows within a form it can see, and which fields and options it can read or change. Together they let you give each team exactly the access it needs — and no more.

Roles and actions#

Access is role-based. Each user has one or more roles, and a role is granted actions on objects (forms, and more). The actions are:

A Super Admin bypasses all checks. The seeded admin@obic.com account is a Super Admin; everyday users should get scoped roles instead.

Row policies#

Object permissions say whether a role can read a form. Row policies narrow that to which records it sees, per form:

• Owner — the role sees only records it created.
• All — the role sees every record in the form.

In the Healthcare Distributor template, for instance, the Sales role gets an owner policy on Leads, Quotes and Sales — reps see only their own deals — but an all policy on shared Customers and Contacts.

Field-level gates#

Two finer-grained controls live on the form itself:

• Visibility gate — a field is hidden unless another field holds one of a set of values, so sections appear only when they're relevant.
• Report gate — actions like Print PDF stay disabled until a record reaches an allowed state (for example, status is Approved or Sent).

Option gates#

The most granular control is on individual dropdown options. For any option value you can set:

• Allowed roles — which roles may set this value. A rep might move a deal to Pending, but only a manager can mark it Approved.
• From states — which prior values may transition to this one, so a status can only advance along a valid path.
• Terminal — selecting this value locks the record against further edits — useful for a final Closed or Cancelled state.

Option gates turn a plain dropdown into a guarded workflow without writing any code, and pair naturally with flows that react to those same status changes.