Platform

Availableapp.erp.io

Platform

Twelve applications, one front door. The shell owns who you are, which company you are acting for, and what you are allowed to open. Everything else is a module.

Origin
app.erp.io — all modules
Identity
One account, many organisations
Entitlement
Per organisation
Access
Narrowed per person

What the shell owns

The shell is the part of erp.io that is not any particular application. It holds accounts, organisations, membership, roles, module entitlement, billing, the audit log, and the mechanism that signs you into a module without a second login. Modules hold everything else.

The division matters because it is what makes the suite a suite rather than a bundle. There is exactly one user directory, one place where a leaver is removed, one bill, and one place to answer "who did that". A twelve-app estate where each app owns its own users is twelve of each of those, and in practice it means nobody is ever quite sure who has access to what.

The rail

The narrow strip down the left of every screen in the suite is the module rail. It shows the modules your organisation has enabled, minus anything removed from you personally, and it is present inside modules as well as in the shell — so switching from Accounting to CRM is one click from anywhere.

Rail links go straight to the module, not through the sign-in hand-off. That is a deliberate performance decision: routing every module switch through the token mint made it three sequential round trips and about two and a half seconds before anything rendered. Going direct works because the suite shares one origin, so a module that has no session of its own can see the shell cookie and start the hand-off itself.

app.erp.io/home
Your suite
AccountingBooks
CRMPipeline
ProjectsWork
ChatMessages
SignDocuments
CFOForecast
The rail, present on every screen. The active module is highlighted; the rest are one click away.

Names and keys

Four modules are stored under a key that is not their name. You will see the keys in API responses, in the audit log, and in entitlement records, so they are worth knowing.

Product nameStored keyWhy it was not renamed
AccountingfinanceIt is the audience claim on every hand-off token already issued.
PhonysdrRenaming would sign every existing customer out of a module they are entitled to.
ChatmessagingSame reason. Only the label moved.
ProjectspmSame reason.
Both names work on the way in

Anywhere you type a module name — a sign-up URL, an API parameter — the product name and the key both resolve. /sign-up/accounting and /sign-up/finance reach the same door. Everything downstream speaks the canonical key.

In this section

What this does not do

No cross-organisation view

Nothing in the shell reads across two organisations. Switching is the only way to see another.

No groups

Roles and module access attach to a person. There is no group or team object to attach them to instead.

No custom roles

The three roles are fixed. Finer control is module access, not a new role.