Skip to content
Support
  • There are no suggestions because the search field is empty.

Security, Roles & Governance

Vince Platform handles the security underneath App Builder. This page is the reference for tenant administrators and anyone curious about how access, roles, and governance work end-to-end. Most end users don't need to read this — they just need a role assigned and they're good to go.

Two things called "roles"

There are two different role concepts in play. Keeping them straight will save you confusion.

Concept What it controls Where it lives Who sets it
Vince Live role (App Builder permission is one part of it) Whether someone can use App Builder and everything else in Vince Live, and at what level (Read / Run / Write / Deploy / All per permission) Vince Live admin → Roles Tenant administrator
InApp Roles What users can see or do inside a specific app (e.g., "supplier" vs "approver") The App Builder editor for that app App builder

In short: the Vince Live role lets someone use App Builder along with everything else in Vince; InApp Roles shape what they see within one specific app.

Vince Live role: App Builder permission

The App Builder permission is one of the permissions you can grant within a Vince Live role. It has five levels: Read, Run, Write, Deploy, All. For the full matrix and step-by-step setup, see Onboarding App Builder.

Recommended baseline:

  • Viewer (Read) — for managers who want visibility but won't run anything
  • End user (Run) — most users; they open and use apps
  • App builder (Write) — the small team building apps
  • Deploy — granted to a smaller group, usually app owners
  • All — reserve for tenant administrators

InApp Roles: per-app visibility control

App builders can define roles inside a specific app to control what different users see or do once that app is running. For example, in a supplier portal you might have an "internal" role that sees all suppliers and an "external" role that only sees their own data.

InApp Roles are set up in the App Builder editor when you build the app — see Building Apps (UI).

InApp Roles are not the same as Vince Live roles. They only affect what the generated app does; they don't grant access to App Builder itself.

External users and portal access

App Builder apps can be used by external users (suppliers, transporters, customers) as well as internal staff. External users:

  • Sign in with their own Vince Live credentials
  • Have Vince Live roles assigned by the tenant administrator (typically Run-only)
  • See only what the app's InApp Role logic and the underlying Vince Live permissions allow

The same security guarantees apply for external users as for internal users: every call still goes through the Vince Platform, which checks roles and permissions on every request.

Least-privilege guidance

A few practical patterns that keep things safe and tidy:

  • Grant the lowest level that works. If a user only needs to view dashboards, Read or Run is enough. Don't give Write unless they actually need to build.
  • Use groups, not individuals. Assign roles to user groups, not to individual users. Easier to maintain.
  • Keep Deploy small. Production publishing should be a deliberate, gated act. Don't spread Deploy widely.
  • Review roles regularly. Once a quarter, look at who has Write or Deploy and confirm they still need it.

For full Vince Live access management depth, see the Access management reference.

Auditability and logs

Two places to look for audit information:

  • App Bridge logs — visible in the App Builder editor, show every request and response between the running app and the Vince host. Used for debugging individual app behavior.
  • Vince Platform audit logs — the platform-wide audit trail (role changes, configuration changes, etc.). See Audit logs.

For audit log configuration and filtering, see the Configure Audit Log Filters video tutorial.

Secrets and credentials

A short list of don'ts that come up a lot:

  • Don't put secrets in prompts. Passwords, API keys, customer-identifying information — these are sent to the AI as text. See Prompting & Best Practices → What to avoid.
  • Don't paste credentials into the tenant prompt. The tenant prompt is for brand and conventions, not for storing secrets.
  • Don't share API keys. Each environment (dev / test / prod) should have its own key.

If your app needs to authenticate against an external system, do it in a workflow with proper connection settings, not in the app itself.

Tenant isolation

Each tenant runs in its own isolated context. The Vince Platform enforces tenant boundaries at every level — workflows, tables, generated apps, and the AI's access to schemas. One tenant's app cannot see or affect another tenant's data.

For full security architecture details, see Vince Platform Security Overview.

Common security pitfalls

Things that have caused issues in real deployments:

  • Granting Write or Deploy too widely. Limit the people who can publish. Use Read or Run for viewers.
  • Forgetting to remove access when someone leaves. Build a regular review into your offboarding process.
  • Putting confidential data in a tenant prompt. Brand colors are fine. Customer lists are not.
  • Using one role for everything. Separate roles by responsibility — Viewer, End user, Builder, Owner — even if it feels like overkill at first.
  • Skipping the user-acceptance test after a role change. Ask the user to sign in and confirm they can do what they should and can't do what they shouldn't.

Quick reference

  • Vince Live role — controls all Vince Live access, including App Builder (Read/Run/Write/Deploy/All per permission)
  • InApp Roles — control what users see inside a specific app
  • Tenant administrator — assigns roles to users and groups
  • Audit logs — Vince Platform audit log; App Bridge logs for app-level debugging

Further reading

Vince Platform docs:

Video tutorials:

Where to go next