Configuration is where the organization itself is set up — who works here, what they can do, where you operate and what you are connected to.
What it covers
| Area | What it controls |
|---|---|
| Business locations | The sites you operate from |
| Settings | Organization-wide behavior |
| Users | Who can sign in |
| Groups | Collections of users that carry roles together |
| Roles & permissions | What each role may do, and what it sees |
| Password policy | Credential rules |
| Integration config | Connected third-party services |
| Escalation | What happens when work breaches its target |
| Translation | Localized content |
| Blacklist | Blocked values and revoked keys |
Users, groups and roles
Users are invited rather than self-registering. An invitation is validated and then completed by the person receiving it, which is where they set their password.
Roles carry three things: what records the holder may act on, what parts of the console they may load, and which menus they see. Groups let you assign a set of roles at once rather than per user.
Role & Permission › Menu access sets which screens a role opens, one tab per app: Appmint, Business Made and Mobile app (the phone app's home grid, bottom tabs and More menu, stored as /mobile/<group>/<item> paths). An empty list leaves the role unrestricted in that app; ticking screens restricts it to those; "no access" shuts the role out and wins over any other role the person holds. Built-in roles nobody has edited follow their default tier — Owner everything, ConfigAdmin admin screens, PowerUser and ContentAdmin manager screens, Publisher and Reviewer maker screens, User the everyday ones, Customer and Guest none. Menu access is editable even on built-in roles. How clients read it: Menu access.
The console adapts navigation to the signed-in role, but access is enforced on the server. A hidden area is still protected, and an unhidden one is still checked.
In the root organization and the shared organization — the ones that run the platform — staff see every menu, including root-only areas and optional apps other organizations only get once they set them up. Customer and guest accounts stay restricted there too.
Beyond roles, individual records can carry their own requirements — a document can demand approval rights that the role alone does not grant. See Identity and access.
Security settings
Organization-wide security controls live here:
- Two-factor authentication — require it for everyone
- New device verification — challenge unrecognized devices even without 2FA
- New device alerts — email on first sign-in from a new device
Quick sign-in behavior for shared point-of-sale devices — whether a card tap needs a PIN — is configured separately.
Locations
Locations are what most of the operational surface scopes to: inventory, staff, schedules, service points and reporting. Define them here before setting up operations.
Integrations
Third-party connections — payment providers, carriers, ad platforms, email and messaging services, marketplaces — are configured and authorized here. See Integrations.
Test on an integration shows the provider's own answer when it fails — 429 You have no credits remaining…, 401 API key is invalid — rather than a bare status code, so you know whether to fix the key, the account or the settings.
A saved change takes effect at once. Saving (or deleting) an integration drops every running copy of it — including the copies other organizations use when it is a shared integration — so the next call is made with the new key or settings. There is no restart to wait for.
Which AI an organization uses. An organization's own active integration marked for AI comes first; without one, the shared organization's is used, and the deployment's default provider only after that. An inactive integration is never used.
Data transfers between organizations
Configuration › Data Transfers copies records from your organization into another one — and nothing leaves until an admin on the receiving side accepts. The same lists are in Database › Import, Export Data as Org Transfers and Send to Another Org, and a data table's own toolbar can start a transfer with the rows you ticked.
The screen is two lists, incoming first (those have a decision waiting on you) and outgoing, plus Send data to another organization. Sending and deciding are for ConfigAdmins.
Sending. Build the transfer one collection at a time: each line is either the entire collection or the rows you ticked in its data table, and a collection is only counted when you add it. Type the receiving organization's id — it is checked as you type, and Send now stays disabled until an organization answers to it. The Studio sends copies: the originals stay where they are. One request carries at most 100,000 records; narrow it or split it if it is larger.
Receiving. The receiving organization's admins get a platform notice and an email. Opening the request shows who is asking, what they want to send, whether it is a copy or a move, and by when. Accept starts the transfer in the background; Decline takes a reason. The sender can Withdraw a request while it is pending. A request nobody answers expires after 7 days.
Outcome. A request is pending, then running, and ends completed, partial or failed — or never runs, as rejected, cancelled or expired. When a transfer finishes, both organizations get a notice and an email with the counts, and a partial or failed transfer lists why records did not land, grouped by reason (a duplicate, for example, is described as a record that is already there).
Blacklist
Values and API keys can be blocked outright. A blocked key is rejected before a request reaches anything, which is the fast path for cutting off a leaked credential without waiting for a rotation to propagate.