Security & Roles
Vince Platform manages security beneath App Builder. This page covers platform-level roles, governance practices, external user access, and audit capabilities. It is aimed at tenant administrators and those responsible for access control.
For per-app visibility rules configured during development, see In-App Roles.
Two types of roles
App Builder involves two distinct concepts both called "roles":
| Type | Controls | Configured by |
|---|---|---|
| Vince Platform Role | Whether someone can access App Builder and at what level | Tenant administrator in Vince Platform admin |
| InApp Role | What a user sees and can do within a specific app | App builder in the App Builder editor |
These are independent. A user needs a Vince Platform role to access App Builder; InApp Roles then govern what they see inside a particular published app.
Vince Platform role: App Builder permission levels
The five App Builder permission levels and their intended audiences:
| Level | Intended for | What they can do |
|---|---|---|
| Read | Managers needing visibility | View apps and descriptions in the Concept Catalog |
| Run | Standard end users | Open and use published apps |
| Write | Developers building apps | Build, edit, and use apps — cannot deploy |
| Deploy | App owners | Build, edit, deploy, and use apps |
| All | Tenant administrators | Same as Deploy |
Keep Deploy access restricted to a small group. Most builders only need Write — they can develop fully and hand off publishing to an owner.
Connection permissions
App builders need at least Read access to the Connections used by their workflows. The platform may automatically add Metadata permissions when a Write-level role is saved. Read is sufficient for most builders and all end users.
Metadata permissions control access to locally stored M3 API schema data — relevant only when using the M3 API step in Workflow Builder.
External users and portal access
External users (suppliers, transporters, customers) access apps through individual Vince Platform credentials:
- Tenant administrators assign them a role — typically Run only.
- InApp Role logic in the app controls what they see.
- Every request from an external user passes through the same Vince Platform verification as internal users — there are no reduced security guarantees.
Tenant isolation is enforced at the platform level. One tenant's app cannot access or modify another tenant's data, regardless of how the app is built.
Can I build customer-facing apps?
Yes, for customers and partners you know. Supplier portals, customer order-status pages and transporter apps are typical examples. Such an app works like this:
- Each external person has their own Vince Platform user, created by your tenant administrator and given a role, usually Run only.
- In-App Roles in the app decide what each user sees, for example only their own orders.
- The data comes from your workflows and tables, so the same business rules apply as for your own staff.
App Builder is not designed for public apps where anyone can sign up on their own: every user of an app is a Vince Platform user that your administrator gives access to.
Least-privilege guidance
- Grant the minimum permission level that allows the user to do their job.
- Assign roles to user groups rather than individuals — easier to audit and revoke.
- Keep Deploy access to a small, named list.
- Review Write and Deploy assignments quarterly.
- Remove access promptly during offboarding.
- Use Read or Run for anyone who only needs to view or use apps — don't assign Write by default.
What not to put in prompts
Prompts and Tenant Prompts are sent to the AI as text. Never include:
- Passwords or API keys
- Customer-identifying information
- Environment-specific credentials
Authenticate external systems through workflows with proper connection settings, not through prompt text.
Audit and logging
| Tool | What it covers |
|---|---|
| App Bridge logs | Every request-response cycle between a running app and the Vince host — use for debugging individual app behaviour |
| Vince Platform audit logs | Platform-wide trail of role changes, configuration changes, and administrative actions |
| Your own audit log table | Who changed which record in your app's tables, when, and what it was before — you set this up yourself, see Audit log for your app |
Common security pitfalls
- Giving Write or Deploy access too broadly
- Forgetting to remove access when someone leaves the organisation
- Storing confidential data in the Tenant Prompt
- Creating a single catch-all role that spans multiple responsibilities
- Skipping user-acceptance testing after changing roles
Further reading
- Concepts & Architecture — permission levels and how to assign them
- In-App Roles — per-app visibility control during development