Security

Security administrators manage two layers: functional permissions (what a user can do) and extranet access (which records a user can see).

Users

A user account has a user name (we recommend an email address), a display name, an Active flag, and a Lockout date. From a user search, the bulk options are:

Option	Effect
Lock / Unlock	Sets or clears the lockout date.
Activate / Deactivate	Allows or blocks sign-in without deleting the account.
Reset Password	Emails a password reset link to active users.
Add Role / Remove Role	Changes role membership for every selected user.

Each of these is written to the security log. A user’s summary page also shows their roles, memberships, setting overrides, security log activity, API keys, and IP restrictions.

Impersonation lets an administrator act as another user to test their access. It requires an impersonation permission, is recorded in the security log, and can be disabled with the ImpersonationEnabled setting.

Roles and permissions

A role groups permissions; users can belong to several roles. Most permissions follow the pattern {Module}{Operation}:

Permission	Example	Allows
Search	ContactSearch	Searching the module
Select	ContactSelect	Reading a single record
Insert / Update / Delete	ContactUpdate	Creating, changing, or deleting records
Home, Dashboard, panels	ContactHome	Showing pages and panels in the UI

When you add statements, services, and templates, QBO creates matching permissions automatically the first time they are used. Members of the Administrators role have every permission.

To build a role quickly, use Record on the role’s Permissions panel (when recording is enabled). Start recording, run through the work the role should do in another window, then save. QBO grants the role every permission it used.

Universal Access

A role marked Universal Access bypasses row-level security; its members see every record. Never give it to partner or vendor users.

Group access and extranet security

Partner users see a record only when a group they belong to has been granted access to it:

1. Membership: put the user in a group, typically their organization (from the user’s Membership panel).
2. Group access: grant that group select, insert, update, or delete on records. From the Group Access home page, filter by role, organization, or user and use Grant Access, Grant Access (Include Related), or Revoke Access. Templates, labels, matrices, reports, roles, and states can be granted this way, as can individual records from the Group Access panel on any summary page.

Most access is granted for you. When a record is saved with an assigned organization or person, QBO grants access to those groups, and child records inherit access from their parent.

Template extranet settings

Each template decides how its records take part:

Setting	Behavior
None	Records don’t create access rows.
Self	Access is granted on the record itself.
Family	Access is granted on the record and its children.
Template	Users with access to the template can see its records; no per-record access needed.

Process templates always use Family, so access to a process extends to the workflows, tasks, documents, and messages beneath it.

IP restrictions

Add IP address rules to restrict sign-in to the whole system, a role, or one user. An address may use SQL wildcards (10.1.%). Check Exclude to block a range instead of allowing it. If no rules exist, sign-in is unrestricted. Once any rule exists, an address must match an allow rule and no exclude rule.

Single sign-on

QBO supports OpenID Connect and OAuth sign-in with Google, Microsoft, and Facebook, plus custom OpenID Connect providers, such as your corporate identity platform. Two application settings control the sign-in page:

Setting	Example	Purpose
AllowedSSOLoginList	Google,Microsoft	Which provider buttons to show
AllowLocalLogin	false	Whether to show the user name and password form

Automatic provisioning: a pre-validate statement can run on each SSO sign-in. It can create the user, sync role membership from the provider’s group claims, and grant organization access from claims, so your identity provider stays the source of truth.

Custom login methods: for a provider that exposes its own authentication API, QBO can call that API (described by an OpenAPI specification) and process the response with a statement that returns the user. Routes named sso/authenticate, sso/authenticate/request, and sso/authenticate/response connect the pieces.

API keys and access links

An API key (SecurityAccess) lets a system or a one-off recipient act as a specific user account:

Property	Purpose
Person	The account the key acts as. The key can do anything this user can.
Enabled / Expires	The window when the key is valid.
Remaining logins	Limits how many times the key can be used.
IP mask	Restricts use to matching addresses (SQL wildcards allowed).

Key templates set defaults: allowed logins, duration, and whether expiry starts at creation or at first use. Use them for one-time links, such as sharing a document with an outside party.

Tip

Create a dedicated user for each integration, grant it only the permissions and group access it needs, then issue the key. Never issue keys for an administrator’s account.

Password and login settings

Setting	Default	Purpose
LoginLockAttempts	3	Consecutive failures before lockout
PasswordRE / PasswordError	6+ characters, mixed case, digit, symbol	Password policy and its message
PasswordExclusionWords	(none)	Words a password may not contain
PasswordHistoryReuse	3	Distinct passwords before one can be reused
PasswordResetLinkDuration	30	Minutes a reset link is valid
ApiKeyEnabled	true	Accept API keys
ImpersonationEnabled	true	Allow impersonation (disable in production)
LicenseRequired	false	Require license acceptance at first sign-in
HttpsRequired	true	Redirect HTTP to HTTPS

Policy documents are published on the Quandis Trust Center.