Roles and permissions

Most people in your organisation need no permission at all. A permission is for the few things beyond someone’s own work, like setting up the AI or letting people in. A role is a named set of permissions. Someone with several roles has every permission any of them holds.

Work needs no permission

Someone who holds only Member, the role everyone has, can do almost everything. They start topics and initiatives and own them. They work on what others share with them, as each owner allows. They make their own personas and skills, templates and flows.

They make boards and lists, share them as they like, and make fields, which belong to the organisation from the start. They connect their own tools, propose changes to the Landscape, and read the Models, Connections and Repositories pages. They connect their own assistants within what the organisation allows, and see their own use of AI on their profile.

The AI and the tools

With Manage models, someone looks after everything on Models. It covers the providers and their keys. It also covers the models the organisation keeps, the three defaults, and their list prices. It also opens the whole organisation’s Usage. Give it to whoever holds the provider accounts and watches the bill.

With Manage all connections, someone changes or disconnects any connection on Connections, not only their own, and configures the knowledge webhook. Everyone still adds connections and manages the ones they made.

Repositories and their analyses

With Manage repositories, someone adds, fetches, edits and removes repositories, and the Git hosts they’re cloned with. Its line on the screen also says “analyse”, but analysing takes the next permission. Someone who looks after the code and its analyses needs both.

With Analyse repositories, someone scans a repository and chooses the recipes, guidance and schedule its analyses follow, without adding or removing any. They start, cancel and retry an analysis, and write and change the organisation’s recipes.

People and roles

With Invite people, someone sees Members with Invite, and sends, resends and revokes invitations there. Without Manage roles, they see Members alone and offer only roles whose permissions they hold. A support lead whose Support role holds it can bring in a colleague as Member or Support, never as Administrator.

With Manage roles, someone makes and changes roles and chooses who holds them. They can give any role to anyone, themselves included, so give it only to people you’d make administrators. It opens all of People’s pages, with Roles on each person in Members. Support is where they let Emargen support in, and the Agent access tab shows too. Emargen won’t take it from the last person who holds it.

The organisation’s own settings

With Launch the organisation, someone can skip a step of setup and open topics and initiatives for everyone. It matters only during setup.

With Manage organisation settings, someone keeps the settings that apply to everyone. On the Workspace page, that’s the name, forwarding addresses, slide pictures, offline reading, working hours, working days and Academy edits. They also keep the workspace’s checks, shown at every Kickoff. They can rename, merge and delete labels, delete fields, and change fields others made. They can change or delete a shared board or list that’s open to everyone and has no owner. With Manage roles too, they set what agents may use on Agent access.

Shared ways of working

With Manage personas and skills, someone keeps the shared personas and skills, and picks the persona new people start with. With Manage templates, someone keeps the shared topic templates and flows. Everyone can still make their own.

With Approve landscape changes, someone approves or rejects what people and agents propose for the Landscape, and changes it directly. Everyone may propose, but whoever holds this decides.

Building apps

With Build apps, someone asks Emargen for new apps, and builds and opens new versions of the apps they edit. Everyone can still use the apps shared with them, and suggest changes.

Approving initiatives

With Approve initiatives, someone approves a published initiative they can see, from its Kickoff, unless they edit it. Waiting approvals show in their Decisions. Owners can approve their own initiatives without it. With Approval gate on, someone else must approve.

Any of these permissions except Build apps also opens Plan, under Admin, with the organisation’s plan and its limits.

Roles from single sign-on

With your organisation’s single sign-on, your people can get Emargen roles from their company roles. Someone with Manage roles chooses which Emargen roles each company role gives, under From single sign-on on Roles & permissions. People then get those roles at every sign-in, beside any given by hand.

A role your organisation gives can’t be removed in Emargen. It goes when your organisation takes the company role away, or when someone changes what that company role gives. Sign-in never replaces the roles given by hand. We built it that way so the Administrator role the organisation started with always stays.

Built-in roles

Administrator holds every permission, including any Emargen adds later, and whoever set the organisation up holds it first. Member holds none, and everyone holds it. App builder holds only Build apps. Built-in roles can’t be renamed or deleted, and their permissions don’t change. Only who holds them does.

The rest of the rules every role follows are in People and roles.

Next

How to

• Make a role
• Invite people

Page by page

• Roles & permissionswhere the roles and permissions are kept.

Guides

• Running Emargen for your organisation