Skip to main content
Ainomos gives rights in two separate ways. Organisation roles apply across the whole organisation: running the settings, handling maintenance, or reading one kind of decision everywhere. Room responsibilities say who decides inside one room: its owners, deciders and curators. Being a member of a room lets you work in it. Only a responsibility lets you decide there.

Organisation roles

Decisions come in three types: architecture decisions (ADR), business decisions (BDR) and security decisions (SDR). Some roles read one type everywhere. Readers and auditors find these decisions under Cross-room decisions in the knowledge library. A reader role only widens reading. Deciding still needs a responsibility in the room.

Grant or revoke an organisation role

Who can do this: platform admins. Open Settings, then Roles & permissions. Under Who holds what, each role lists the people who hold it. To grant a role, find a person in that row and choose Add. To revoke it, choose the cross on the person’s name. Ainomos asks you to confirm, applies the change at once and records it as evidence.
  • The Room owner row is for reading only. Owners are Granted inside the room.
  • Maintainers are granted on the person’s sheet under Users, where every other role can be granted too.
  • The last active platform admin cannot be revoked.
  • The auditor role cannot go to an account that already holds a role in your organisation’s top room. Invitations add people to the top room by default, so give the auditor a separate account.
  • A role that comes from your identity provider is controlled there.

Room responsibilities

Each delegation is a part of the owner’s own rights, so the owner can always do what a decider or curator does. When nobody holds a delegation, the task falls back: drafts go to the owner, and a memory without its own curator is looked after by the room’s curators, or by the owner when there are none. The room then shows Responsible: owner. That is normal, not an error. Apps never hold a responsibility.

Who can do what in a room

What is inherited

Responsibilities are not inherited down the tree. When a room is created, the parent’s deciders are copied into it once, and after that each room keeps its own. Owning a department gives no rights in its teams. Rules do pass down; see rooms.

Grant a responsibility

Who can do this: owners of the room.
1

Open the room's responsibilities

Open the room, choose Room details and go to Responsibilities.
2

Choose what to grant

Under Grant a responsibility, pick the Responsibility: Owner, Decider for ADR, BDR or SDR, Curator for the whole room, or Curator for memory for one memory.
3

Choose who

Under Grant to, choose Person and pick them. The person must already be a member of the room; add them under Members first.
4

Grant it

Choose Add. To take a responsibility back, choose Remove next to the holder.
The last owner cannot be removed. Add another owner first. Removing someone from the room also ends their responsibilities there. A platform admin who does not own the room may grant or remove the Owner only, and must answer Why are you changing the owner?. Ainomos keeps the reason in the evidence. Use this to hand over a room whose only owner has left.

Groups from your identity provider

A responsibility can also go to a group in your identity provider. In the same form, choose Group under Grant to, then the Identity provider and the Group. The section shows how many members have signed in so far.
  • Rights apply at each group member’s next sign-in, and they join the room as members.
  • Removing the group, or changing what it maps to, ends the rights it granted at once.
  • A person also granted by hand keeps their rights.
  • A group that holds a room’s last owner cannot be removed.
Who can do this: a platform admin who is also an owner of the room. Groups need an identity provider connected directly to Ainomos. Organisation roles can come from groups too, set up under identity and single sign-on.

Check what someone can do

Open Settings, then Users, open the person and choose Show rights. The preview lists, for each of their rooms, what they may do and where each right comes from, for example from an owner responsibility. It also shows their organisation roles and their direct views under user visibility. Ainomos works this out with the same checks that protect the real actions.

The platform operator

The people who run your installation are not accounts of your organisation, so there is no role to grant them. An operator who enters your organisation to help has full administrator rights there. A strip at the top of their screen names your organisation, and each of their actions goes into a separate operator log.