Every integration starts as one person’s login. That is fine while you are setting it up and stops being fine the first time somebody is on holiday and a colleague needs to check whether an order synced.
The usual fix is to share the password, and the usual consequence is that everyone who can look at sync logs can also change billing details, cancel the subscription, or disconnect a storefront. The audit trail becomes a single name, so when something changes unexpectedly there is nothing to examine.
OrderWeave is multi tenant underneath, which means it was built from the start on the assumption that one login is not the same as one company. Inviting people is a few clicks, and each of them gets their own account, their own record in the log, and only the access their job needs.
Inviting someone
Go to Settings, then Team, and add a colleague by email with a role. They receive an email, set their own password, and appear in your team list. Until they accept they show as invited, so you can see at a glance who has actually joined.
Three account roles cover most structures. An owner can do everything, including billing and ending the subscription. An admin runs the day to day without touching the money. A billing role sees invoices and payment details and nothing else, which is the one your accountant wants and the one you least want to hand out by accident.
Removing a person takes the same few clicks, which matters more than it sounds. Somebody leaving should take ten seconds to handle, and should not involve changing a password that four other people are also using.
When roles are not enough
Three roles are a reasonable starting point and a poor finish. Real teams have a warehouse supervisor who should see stock and dispatch but not pricing, or a marketing contact who needs to manage storefront categories without reaching customer records.
Permission sets exist for that. There are around ninety distinct permissions underneath, each one gating a specific thing: viewing audit logs, managing e-commerce sites, creating a dispatch log, rolling back an import, running a GMC sync, generating barcodes. A permission set is a named bundle of them that you build once and attach to people.
Building sets rather than configuring each person individually is what keeps this manageable. You define what a warehouse supervisor is allowed to do once. The next supervisor who joins gets that set, and when the definition changes it changes for everyone holding it.
Access is scoped to the business as well as the person
If you run more than one ERP instance, and plenty of our customers run several, permissions are scoped per instance rather than globally. Somebody can be an admin on one business and have no visibility of another at all.
That scoping is enforced server side on every request rather than hidden in the interface. A person who should not see another company’s orders cannot reach them by changing a URL, because the list of instances they may touch comes from their login and not from what they asked for.
It leaves a record
Every action is attributed. The activity log and the audit log show who did what and when, which turns the awkward conversation about an unexpected change into a short one.
This is also the part that matters at the other end of a procurement process. Somebody reviewing you on behalf of a larger customer will ask how access is controlled, whether it can be scoped, and whether actions are attributable. Being able to answer with a feature rather than a policy document is the difference between a short conversation and a long one.
Where to start
Invite one person with the role that fits, and see whether the three roles are enough for how you work. Most teams find they are for a while, and reach for permission sets at the point where somebody needs an unusual combination.
See pricing or talk to us about how your team is set up.