The Free Plan Can Do Everything, Twice
A plan controls two entirely separate things: which permissions exist in your workspace, and how many of certain things you may have. They do not move together, and the free plan is the clearest demonstration — it grants every permission in the product and caps you at two users.
The free plan can do everything. It can do everything with two people, which is a completely different sentence.
Our take
Separating capability from capacity is the right way to build plan tiers and it is unusual enough to be worth explaining. The common approach withholds features from smaller plans, which makes evaluation dishonest — you cannot tell whether a product suits you because you have not been allowed to see the part that would decide it. Here the free plan grants every permission in the product and caps the workspace at two users. You get the whole thing, at a size that is genuinely useful for one or two people and genuinely unworkable for a team, which is exactly the right pressure. The paid tiers between then do restrict by capability as well, and that is where the model gets more conventional — the interesting design is at the ends.
Two configurations, keyed on the same name
A plan name resolves in two independent places. One decides which permissions may be granted to anybody in the workspace. The other decides how many users, employees, saved reports, workflows and webhooks the workspace may have.
Neither knows about the other. That is why the answer to "what does this plan get me" is two answers, and why the free plan is a genuinely useful thing to evaluate on rather than a demonstration.
What each plan may do
Permissions are organised into twenty-five groups — inventory, asset tracking, procurement, vendors, people, projects, support, sales, accounting, automation, reports, custom fields, users and roles, security, the document vault, integrations, insights, tax, notifications, logs and trash, and a few more. A plan describes what it does with each group.
| Group mode | What it grants |
|---|---|
| Full | Every permission in that group. |
| Read | Only the permissions whose names begin with view — so the group is visible and nothing in it can be changed. |
| Custom | Nothing from the group itself. What is granted comes from the plan's explicit allow list instead. |
On top of the group modes, a plan can name individual permissions to add and individual permissions to remove, and the removals are applied last. That is what makes a tier expressible as "everything in these groups, plus these two specific things, minus that one".
Two plans skip all of that and resolve to every permission in the product: the free one and the top one. Between them sit three tiers that shape access by group, and the read mode is the one worth noticing — a plan that gives a group read access produces a workspace where the whole module is visible and inert, which is a much better way to demonstrate something than hiding it.
A module you can see and cannot use tells you whether you want it. A module you cannot see tells you nothing.
How many you may have
The second table is a set of ceilings, and an absent ceiling means no limit rather than zero — which is why the free plan and the top plan look similar in it and mean opposite things.
| Limit | Free | Basic | Pro | Premium | Enterprise |
|---|---|---|---|---|---|
| Users | 2 | 3 | 5 | 10 | No limit |
| Employees | No limit | 10 | 25 | 100 | No limit |
| Saved reports | No limit | 0 | 3 | 50 | No limit |
| Workflows | No limit | 0 | 2 | 25 | No limit |
| Webhooks | No limit | 0 | 1 | 5 | No limit |
| Actions per workflow | No limit | 0 | 10 | 50 | No limit |
| Workflow runs per day | No limit | 0 | 250 | 5,000 | No limit |
| Minimum schedule interval | None | None | 60 minutes | 15 minutes | None |
The free plan's only ceiling is people
Everything else on the free plan is unlimited, which reads as a mistake and is the design. Two users can register as many employees, save as many reports and build as many workflows as they like — because the constraint that makes a free tier sustainable is the size of the organisation using it, and every other ceiling would just make the evaluation less honest. A two-person business that outgrows this is a two-person business that has become a bigger one.
The last row is the interesting one
A minimum schedule interval is a limit of a different kind. It does not cap how many of something you may have; it caps how often an automation may run. An hour on one tier, a quarter of an hour on the next, and unconstrained above that.
That is a resource limit rather than a commercial one, and it is honest to name it as such. A workflow scheduled every minute is a workflow running fourteen hundred times a day, and the difference between a tier that permits that and one that does not is a difference in what the platform is being asked to carry rather than in what the customer is being sold.
A plan is a default, and it can be overridden
Underneath both tables sits a third mechanism: per-workspace permission overrides. Each one names a permission and says allow or deny, and each one can be active or not.
They are applied after the plan has resolved. Allowances are merged in, then denials are subtracted — so a denial wins over both the plan and any allowance for the same permission. That ordering is the safe one: an override intended to remove something cannot be defeated by a plan change that adds it back.
What this means practically is that a plan is a starting position rather than a wall. An organisation that needs one specific capability its tier does not include, or needs one specific capability its tier does include kept switched off, is a configuration change rather than an upgrade or a compromise.
Making the two tables legible
The mechanisms are sound and the overrides make them flexible. What is missing is showing an organisation where it actually stands against both tables before it meets a limit.
Usage against every ceiling
Where you are against each limit in your plan, on one screen, rather than discovering a ceiling by hitting it.
A view of active overrides
Which permissions have been allowed or denied for this workspace beyond its plan, and when each was set.
What an upgrade would change
The specific permissions and ceilings that would move, before the decision rather than after.
We publish scope, not dates.
Scope plan configurationWhat AWRA OpsHub does today
- Two independent plan configurations — one for which permissions exist in a workspace, one for how many of certain things it may have.
- Permissions organised into twenty-five groups, with each plan describing a group as full access, read-only, or handled by an explicit list.
- A read mode that grants only the viewing permissions in a group, so a module can be visible and inert rather than hidden.
- Per-plan allow and deny lists applied on top of the group modes, with denials applied last.
- Ceilings on users, employees, saved reports, workflows, webhooks, actions per workflow and workflow runs per day, with an absent ceiling meaning no limit.
- A minimum schedule interval per plan, capping how often an automation may run rather than how many exist.
- A free plan granting every permission in the product and capping only the number of users.
- Per-workspace permission overrides that can be active or dormant, allowing or denying individual permissions on top of the plan, with denials winning.
More we can add to your workspace
- A usage view against every ceiling, so an organisation sees where it stands before a limit refuses an action.
- A view of the overrides active on a workspace, showing which permissions were allowed or denied beyond the plan and when.
- A comparison of what an upgrade would change, naming the specific permissions and ceilings that would move.
- A warning as a ceiling approaches, rather than a refusal when it is reached.
- Limits expressed per module for organisations that use one part of the product heavily and the rest barely.
- A record of why an override was granted, alongside who granted it.
Where we point you to a specialist
- We will keep the free plan carrying every permission. Withholding capability from an evaluation makes the evaluation dishonest — an organisation cannot tell whether a product suits them if the part that would decide it is behind a paywall. The constraint that makes a free tier sustainable is the number of people using it, and that is the constraint we apply.
- We will keep denials winning over allowances. An override placed to remove a capability from a workspace exists for a reason, and a plan change that quietly restored it would be the most dangerous kind of upgrade.
- Which plan suits your organisation is a commercial decision and stays yours. We will describe exactly what each one grants and caps; recommending a tier from your usage would be selling rather than informing.
A usage view against every ceiling is the contained piece here, and it changes the experience most — a limit met with warning is a planning decision, and a limit met without warning is an outage.
Five questions to ask about plan tiers
What does the free tier withhold?
A good answer sounds like
A clear statement.
What ours actually is
No permissions at all. It grants everything in the product and caps the workspace at two users.
How are capability and capacity related?
A good answer sounds like
Separately configured.
What ours actually is
Two independent configurations keyed on the plan name — one for permissions, one for ceilings.
Can a tier show a module without granting it?
A good answer sounds like
Yes.
What ours actually is
Yes — a read mode grants only the viewing permissions in a group, leaving the module visible and inert.
Can a plan be adjusted for one workspace?
A good answer sounds like
Yes, with the ordering named.
What ours actually is
Per-workspace overrides allowing or denying individual permissions, applied after the plan resolves, with denials applied last.
What does an unset limit mean?
A good answer sounds like
No limit.
What ours actually is
No limit rather than zero — which is why the free tier and the top tier look alike in the ceilings table and mean opposite things.
Evaluate on the free tier, not on a demonstration
Every permission in the product is available on it. Two people can put the whole thing through a real month of work, which is a far better basis for a decision than any walkthrough.
Talk through plansFrequently asked questions
Does the free plan really include every feature?
Every permission, yes — it resolves to the complete set, the same as the top tier. What it caps is the number of users, at two. Everything else on it is uncapped: employees, saved reports, workflows and webhooks all have no ceiling, because the constraint that makes a free tier sustainable is the size of the organisation rather than the size of its data.
What does a read-only group mean in practice?
The module is visible and inert. Only the permissions whose names begin with view are granted, so somebody can open the screens, see the data and change nothing. It is a much better way to represent a tier boundary than hiding the module, because a module you can see tells you whether you want it.
Can we get one feature without changing plan?
Yes. Per-workspace overrides name an individual permission and either allow or deny it, and they are applied after the plan resolves. An organisation needing one capability its tier does not include is a configuration change rather than an upgrade, and the same mechanism can keep a capability switched off that the tier would otherwise grant.
What happens when an override and the plan disagree?
A denial wins. Allowances are merged into the plan's set first and denials are subtracted afterwards, so an override placed to remove a capability cannot be undone by a plan that includes it. That ordering is deliberate — an override removing something exists for a reason, and a plan change quietly restoring it would be the worst possible outcome.
Why does a plan limit how often a workflow can run?
Because that is a resource question rather than a commercial one, and it is more honest to say so. A workflow scheduled every minute runs about fourteen hundred times a day, and a minimum interval of an hour or a quarter of an hour is the platform describing what it will carry at that tier rather than withholding a feature.
Does an unset limit mean zero?
No — it means no limit. That distinction matters most on the free plan, where every ceiling except users is unset, and on the top plan, where every ceiling including users is unset. The two tables look similar and describe opposite situations.
