Team & permissions
In plain English
When it's just you, everyone who logs in is you, and permissions don't matter. The app knows this — if you're a solo shop, all of this is invisible and nothing is blocked.
Once you have a team, it starts mattering. Your customer-service person needs to look up orders. They don't need to change your billing details or delete products. Your agency needs to run campaigns. They don't need to see your revenue.
This screen lets you give each person a role, and the role decides what they can do.
There are six ready-made ones:
| Role | Who it's for | What they can do |
|---|---|---|
| Owner | You | Everything |
| Admin | Your store manager | Nearly everything — not system configuration |
| Marketer | Marketing staff or agency | Campaigns, content, WhatsApp, calendar |
| Analyst | Anyone who needs numbers | Read-only, everywhere |
| Support | Customer service | Customer data, loyalty, carts |
| Developer | Technical staff | API access, analytics, settings |
Pick a role, send an invite, done. You don't need to think about the 101 individual permissions unless you want to.
A note on safety. These checks are built to fail in the safe direction. If something goes wrong while checking whether someone is allowed to do something, the answer is no. It's better to briefly block a legitimate action than to accidentally allow one that shouldn't happen.
How to use it
- Click "Team & Permissions" in the left-hand menu.
- Click "Invite member" and enter their email address.
- Choose a role using the table above. When unsure, pick the more limited one — you can always upgrade.
- Send the invite. They get a link, accept it, and they're in.
- Review your team every few months. People change jobs and agencies get replaced.
- Revoke access the same day someone leaves. Don't wait for the automatic 90-day cleanup.
⏱ ~2 min per person · 💳 Pro+ · 🎯 Right access for each person, nothing more
Why this matters for your business
Most small teams share one login. It's simple, it works, and it carries three costs that only become obvious later.
The first is accidents. Someone deletes a product collection they didn't realise was live. Someone changes a setting they were just looking at. With a shared login there's no record of who and often no way to know what changed.
The second is departures. When a shared password is the only key, everyone who ever knew it still has access. Changing it means telling everyone the new one, which most teams put off.
The third is only a problem when it's a big one. If you sell to enterprise customers, or handle European customer data, or ever want an information-security certification, "we all share a login" fails the check immediately. Individual accounts with defined roles and an audit trail is what auditors expect.
The good news is that this is about ten minutes of work. Six ready-made roles cover almost every real team, and the app handles the rest — including removing people who've stopped logging in.
What this typically unlocks
| What you get | Typical result |
|---|---|
| Accidental changes by well-meaning staff | Sharply reduced |
| Knowing who did what | Complete record |
| Removing a leaver's access | One click, not a password reset for everyone |
| Passing a security review | Achievable — individual accounts, roles, audit trail |
| Dormant accounts left open | Cleaned up automatically at 90 days |
What you actually get
The six roles
| Role | Permissions | Best for |
|---|---|---|
| Owner | All 101 | You. Only one, and it can't be given away |
| Admin | 98 | A trusted manager. Everything except system configuration |
| Marketer | 62 | Marketing staff and agencies — campaigns, content, messaging |
| Analyst | 40 | Read-only across everything. Ideal for consultants and accountants |
| Support | 20 | Customer service — customer data, loyalty, carts |
| Developer | 30 | Technical staff — API access, analytics, settings |
What the permissions cover
101 permissions across 15 areas:
| Area | Permissions | Examples |
|---|---|---|
| SEO | 13 | Run audits, generate content, research keywords |
| Video | 13 | Create strategy, bulk generate, manage tests |
| 10 | Create campaigns, launch, approve templates | |
| Team & permissions | 10 | Invite members, create roles, read the audit log |
| Blog | 8 | Create, publish, bulk generate |
| Feeds | 8 | Create rules, distribute, enable autopilot |
| Customer data | 7 | Create segments, personalise, export |
| Cart | 6 | Create flows, launch, read analytics |
| Admin | 6 | Manage users and plans, configure the system |
| Loyalty | 5 | Configure the programme, award points, manage tiers |
| Settings | 5 | Manage billing, API, general settings |
| Analytics | 3 | Read analytics, revenue, attribution |
| Calendar | 3 | Read, create entries, delete entries |
| Growth | 2 | Read growth data, export reports |
| Decisions | 1 | Read decision intelligence |
You don't need to work at this level. The six roles are sensible bundles. Custom roles exist if you need them.
"Own" versus "all"
Some permissions come in two strengths:
| Permission | What it allows |
|---|---|
blog:create:own | Create and edit their own posts |
blog:create:all | Create and edit anyone's posts |
A junior writer gets :own and can't accidentally overwrite a
colleague's work. When someone with :own access opens something
they created themselves, the system recognises it as theirs and
allows it.
Security properties worth knowing
| Property | What it means for you |
|---|---|
| Fails closed | If a check errors, access is denied. Never the reverse |
| No self-promotion | Owner cannot be granted by invite or by assigning a role |
| One-time invites | An invite link stops working the moment it's used |
| Store isolation | Access is scoped to your shop. Cross-shop access isn't possible |
| Everything logged | Every check recorded with who, when, and from where |
| Auto-cleanup | Inactive 90+ days and access is revoked. Owners exempt |
The 90-day cleanup
| Day | What happens |
|---|---|
| 75 | A warning that the account is going dormant |
| 90 | Access revoked automatically |
Owners are never removed — you can't lock yourself out.
This exists because dormant accounts are the ones nobody remembers to close. The agency you stopped using, the contractor whose project finished, the employee who moved teams. Each is an open door nobody is watching.
If someone is removed and comes back, re-invite them. It takes a minute.
Separation of duties
For sensitive workflows, the app checks that the person approving something isn't the person who created it.
This is a standard financial control — the same principle as requiring two signatures on a large cheque. Someone who can both raise and approve a change has no real oversight.
Two levels:
- When building a custom role, you're warned if it grants both sides of a maker–checker pair. It's a warning, not a block — small teams sometimes have no choice, and it's your call.
- At the moment of approval, the check is enforced. The approver cannot be the author.
How it works (without the technical bits)
Real merchant scenarios
Scenario A — The deletion nobody could explain
Setup. Homeware brand, five people, one shared login. A seasonal collection with 84 products was archived overnight.
Nobody knew who or why. All five had been logged in that day as the same user. No record, no accountability, and a genuinely uncomfortable week.
Recovery took two days of rebuilding.
Afterwards. Individual accounts with roles:
| Person | Role | Could they have done it? |
|---|---|---|
| Owner | Owner | Yes |
| Store manager | Admin | Yes |
| Marketing lead | Marketer | No |
| Customer service | Support | No |
| Bookkeeper | Analyst | No |
Three of the five never needed that ability. With roles in place, the same accident becomes far less likely — and if it happens, the log says who.
Scenario B — The agency that still had access
Setup. Apparel brand switched marketing agencies. The old agency's shared login had never been changed.
Discovered fourteen months later during a security review. The former agency had had full access the entire time.
Nothing bad happened. But their competitor was also a client of that agency, and the brand had no way to prove nothing was accessed — because there was no log.
With individual accounts: the agency's access is revoked the day the contract ends, in one click, and the audit trail shows exactly what was accessed and when.
They also learned about the 90-day cleanup. Even if someone forgets to revoke, a dormant account closes itself.
Scenario C — Read-only for the accountant
Setup. Merchant's accountant needed revenue figures monthly. The existing approach was screenshots by email.
Action. Invited them as Analyst — read-only across everything.
| Before | After | |
|---|---|---|
| Time preparing figures | ~2 hrs/month | 0 |
| Risk of accidental change | n/a | None — read-only |
| Figures out of date | Often | Never |
Analyst is the most under-used role. It's exactly right for accountants, consultants, investors, and anyone who needs numbers but should never change anything.
Scenario D — Passing a security review
Setup. B2B supplier bidding for a large retail contract. The buyer's security questionnaire asked about access control.
Questions they'd have failed on a shared login:
| Question | Shared login | With roles |
|---|---|---|
| Are accounts individual? | ✗ | ✓ |
| Is access role-based? | ✗ | ✓ |
| Are permission checks logged? | ✗ | ✓ |
| Can access be revoked immediately? | ✗ | ✓ |
| Are dormant accounts closed? | ✗ | ✓ |
Setup took about 40 minutes. They won a contract worth substantially more than that.
Scenario E — Separation of duties in practice
Setup. Merchant built a custom role for their content manager including both "create product changes" and "approve product changes."
They were warned, not blocked: one person could raise and approve their own changes, removing the check entirely.
Their situation. Two-person team. Nobody else could approve.
What they did. Kept the role, and set the Owner as approver for anything above a value threshold. The warning had made it a conscious decision rather than an accident.
Why warning beats blocking here. Small teams genuinely can't always separate duties. Refusing would have meant no approval workflow at all — worse than an acknowledged compromise.
Best practices
✅ Give the most limited role that works. Upgrading is easy; un-seeing data isn't.
✅ Use Analyst for anyone who only needs numbers. Accountants, consultants, investors.
✅ Revoke on the day someone leaves. Don't rely on the 90-day cleanup.
✅ Review your team quarterly. Ten minutes, and it catches everything.
✅ Give agencies Marketer, not Admin. They rarely need billing or system settings.
✅ Keep exactly one Owner. It's your recovery path.
❌ Don't share logins. Every scenario above starts there.
❌ Don't give everyone Admin because it's simpler. It removes the entire benefit.
❌ Don't ignore a separation-of-duties warning without deciding consciously.
❌ Don't build custom roles until the six aren't enough. They cover most teams.
Plan tiers
| Capability | Free | Starter | Pro | Agency | Enterprise |
|---|---|---|---|---|---|
| Solo use (no permissions needed) | ✓ | ✓ | ✓ | ✓ | ✓ |
| Six built-in roles | — | — | ✓ | ✓ | ✓ |
| Invite team members | — | — | ✓ | ✓ | ✓ |
| Audit log | — | — | ✓ | ✓ | ✓ |
| Inactivity auto-revocation | — | — | ✓ | ✓ | ✓ |
| Custom roles | — | — | — | ✓ | ✓ |
| Separation-of-duties checks | — | — | — | ✓ | ✓ |
| API tokens | — | — | ✓ | ✓ | ✓ |
| Cross-store team management | — | — | — | ✓ | ✓ |
Frequently asked
I work alone. Do I need any of this? No. Solo shops bypass permission checks entirely.
Can someone make themselves Owner? No. Owner cannot be granted by invite or by assigning a role.
What happens if a permission check fails unexpectedly? Access is denied. The system always fails in the safe direction.
Can I create my own roles? Yes, on Agency and Enterprise plans. Start with the six built-in ones — they cover most teams.
What's the difference between "own" and "all"?
:own limits someone to items they created. :all covers
everyone's. Useful for junior staff.
What if someone is removed after 90 days and comes back? Re-invite them. Takes a minute.
Can an invite link be reused? No. It stops working the moment it's accepted.
Can a team member from another shop see my data? No. Access is scoped to your shop; cross-shop access isn't possible.
Which role should an agency get? Marketer for most work. Admin only if they genuinely manage the store day to day — and even then, not billing.
See also
- Invites, tokens & audit — the practical mechanics
- Agency & multi-store — managing several shops
- Billing & plans — what's included at each tier
- Daily Ops overview — a screen with view/act separation
- Subscriptions overview — behind billing permissions
- GDPR & consent — the data-protection side