Users, roles and permissions

You’ll need: Members — if you cannot see these, the module may be switched off for your business or outside your permissions. An administrator can change either.

Your colleagues in FeePrime are members of the business. Each has a login and a set of permissions that decides which modules they see and what they may do inside them.

Adding someone to your business

This is the first thing a new business needs to do, and it does not work the way most systems do.

You do not create an account for your colleague. They already have their own personal FeePrime account, with a wallet account number. You add them to your business by entering that number.

   your colleague already has        you enter their wallet
   a personal account + number  -->  account number         -->  they can work
                                     and pick their roles         in your business

So the first step is not in the system at all: ask them for their wallet account number. If they do not have an account yet, they create one first — it is theirs, not something you issue.

You can type the number as they give it to you; spaces and dashes are ignored. It must be a personal account number — a business’s own wallet number will be refused, because you are adding a person, not an organisation.

Why it works this way

Because identity belongs to the person, not to your business.

The alternative — you invent a username and a password for your colleague — means every business they work with holds a separate credential for them, and you hold something you can impersonate them with. Here you are granting access to an identity they already own, which is why the audit trail can honestly say they did something.

It also means the leaving process is clean. When somebody leaves, you archive their membership of your business. Their personal account is untouched and still theirs, and everything they did in your business keeps their name on it.

Their name comes from their own profile

Once added, a member’s name is read from their personal profile. There is a full name field on the member record, and it exists as a fallback: if somebody never set a name on their own account, they would otherwise appear as unknown, so an administrator can label them.

If a colleague shows up with no name, that is what to fill in — and it will auto-fill later if they set a profile name themselves.

Two things that will stop you

Already a member. Adding somebody who is already in your business is refused. If they were removed before, archiving is what happened, and re-adding is possible.

Your own permissions. Adding a member is a change like any other, so if you cannot approve in that module, the new member arrives as a pending change for somebody else to confirm.

Members who sign documents

A member record can carry a signatory title, a signature image and a stamp image. These are used when that person approves a document issued under their signature, and the details are captured into the document at the moment of signing — so a certificate reprints identically years later even if the person edits their record or leaves.

If your business issues signed documents, fill these in for the people who sign them, and treat the images as you would a physical stamp.

Permissions are per module, per action

It is not one dial from junior to senior. Rights are granted module by module, and separately for each kind of action — broadly, being able to see records, being able to create or change them, and being able to approve changes.

That is what lets a business say: the storekeeper may enter stock movements but not approve them; the accountant may see every invoice but not touch the product catalogue; the manager may approve purchase orders but has no business in payroll.

                 see    create    approve
  Inventory       yes     yes        no     <- storekeeper
  Invoices        yes      no        no
  Payroll          no      no        no

The consequences you will actually notice

A module is missing from your sidebar. Either it is switched off for the business, or you have no rights to it.

Your saves land in Pending. You can create but not approve in that module. This is a deliberate arrangement, not an oversight.

A button is absent or refuses you. FeePrime tells you plainly that you do not have permission, rather than failing silently.

Disabled members

A member can be disabled rather than removed. They can no longer log in, but every record they created, every change they made and every approval they gave stays exactly where it is, with their name on it.

This is the same principle as archiving. Someone leaving the company must not erase the history of what they did while they were there.

Never share a login

Everything in the audit trail is attributed to whoever was signed in. Borrow a colleague’s login and the system will faithfully record that colleague as the person who changed the price, approved the payment or archived the record. You have not saved time; you have made the history wrong, and you have made it wrong in a way that is very hard to correct later.

If you need access you do not have, ask for it. That is a two-minute conversation.

API keys

A business can also issue API keys so other software can read and write its data. A key carries its own permissions, exactly like a member does, so an integration can be given the narrow rights it needs and nothing more. You are unlikely to create one, but it is worth knowing that “the system did it” usually means a key did it, and that key has an owner.

Try it

On staging.feeprime.com, open the members list and read one colleague’s permissions. Then compare it against what you can see in your own sidebar. The relationship between those two screens is the whole of this lesson.