Getting started · Step 3

Availableapp.erp.io/settings/org/members

Invite your team

An invitation creates the membership before the person exists. That ordering is what makes their first sign-in work.

Invitation carries
Organisation + role
Expiry
Token-based, single use
Counts as a seat
Once accepted
Bulk invite
One address per line

Send an invitation

Open Settings → Members

At app.erp.io/settings/org/members. You need an administrator role.

Enter addresses and pick a role

The role applies to everyone in that batch. Send finance people and contractors separately if their roles differ.

Send

Each person gets a mail with a single-use link. The invitation row exists in your members list immediately, marked pending.

They accept

The link takes them to /invite/<token>. If they have no account, they create one there and the membership attaches to it. If they do, it attaches to the account they are signed in as.

app.erp.io/settings/org/members
Members

14 active · 2 pending · 12 billable

ExportInvite people
Active14Pending2Removed
PersonRoleModulesLast seenSeat
Dana OkoroPlatform adminAll2 min agoBillable
Sam WhitfieldEntity adminAll1 hour agoBillable
Priya RamanMemberAccounting, CFOYesterdayBillable
Tom BairdMemberProjects, Chat3 days agoBillable
[email protected]MemberProjectsInvited
The members list. Pending rows are invitations that have been sent and not yet accepted.

What a role grants

Roles are set at the organisation level and every module respects them. A member cannot be an administrator in one module and not another — that distinction is expressed by module access, which is a separate and narrower control.

RoleCan doCannot do
Platform adminEverything, including billing, members, module entitlement and the audit log.Nothing within the organisation.
Entity adminMembers, module access, most settings.Change the billing relationship.
MemberUse the modules they have access to.See settings, invite people, or read the audit log.

Full detail, including how a module narrows an organisation role further, is on Roles and permissions and Module access.

Seats and the bill

A seat is an active, billable member. Pending invitations are not seats — nothing is charged for an invitation somebody never accepted. Removing a member removes the seat. There is no per-module seat: a person who uses six modules is one seat, which is the main reason the pricing is shaped the way it is.

Clients in the portal are not seats

People who sign in to the Client Portal to see their own work orders are not members of your organisation and are not counted or charged. That is the difference between a portal user and a member, and it is why client-facing work does not scale your bill with your client list.

Do not create accounts by hand instead of inviting

Adding a user row directly — through an integration, a script, or a support request — creates the account without the membership. That account can sign in to the shell and then bounces straight back out of every module, because the hand-off refuses a session with no current organisation. It looks like a broken module and it is a missing row. Always invite.

What this does not do

No groups or teams

Access is granted per person. There is no group object to attach a role or a module to.

No SCIM provisioning

Automatic joiner/leaver sync from an identity provider is not built. Invitations and removals are manual.

No invitation expiry policy

Tokens are single-use but you cannot set an organisation-wide expiry window on them.

Questions

Can I re-send an invitation?

Yes, from the pending row. It issues a fresh token; the old one stops working.

What happens if I invite an address that already has an account?

The membership attaches to the existing account. They keep their password and MFA.

Can somebody belong to my organisation and their own?

Yes. Memberships are independent and they switch between them.