Roles, Groups And Permissions

Your application decides what you can see and do based on the roles you hold. This chapter explains the model behind that decision — what a role is, what a group is, and the layers of checking that happen every time you open a screen — so that "my colleague sees a button I don't have" stops being a mystery.

Nothing here is something you can change yourself. The point is to understand what is happening, so you can describe it accurately when you need to ask for access.

What This Is

Three ideas carry the whole model.

The sentence to remember: permissions hang off roles, never off groups. A group tells the application who you belong with. A role tells it what you may do.

Why It Matters

Applications built on this platform are usually shared by people doing quite different jobs — a sales representative, a warehouse clerk, a finance controller and an external partner may all open the same application and even the same screen.

Rather than build a separate application for each of them, the person who set up your application builds one set of screens and then decides, per role, what each screen reveals. The result is efficient for the business and occasionally confusing for you: the same list screen genuinely looks different for different people, and neither version is broken.

Understanding the model buys you three things:

• You can tell "I do not have access" apart from "there is nothing there."
• You can describe a problem precisely enough that an administrator can fix it in one pass.
• You know what you should not assume is private.

Roles

A Role Is A Job Description

A role is a named bundle of permissions — "Sales Representative", "Warehouse Clerk", "Invoice Approver". The name is chosen by the person who set up your application, so it usually mirrors a real job in your organization.

Everything you can do in the application traces back to a role you hold. If nobody has granted a permission to any of your roles, the corresponding menu entry, list, field or button is not there.

Your application also comes with a handful of standard roles that exist in every installation, with generic names such as "User", "Reader", "Publisher" and "Editor". They are broad by design — the standard "Editor" role, for instance, grants read, create, edit and delete access on every kind of business record — which is why an administrator will usually give you narrow, purpose-built roles instead. You will not normally see which roles you hold: there is no place in the application that lists them back to you, so you have to ask.

You Can Hold More Than One Role

Holding several roles at once is normal and expected. A team leader might hold "Sales Representative" (so the day-to-day screens work) plus "Sales Manager" (so the approval buttons appear).

Roles add up. They never subtract. When two of your roles disagree — one grants something, the other does not — the more generous answer wins. Adding a role can only ever widen what you see; it can never take something away.

This has a practical consequence worth knowing: if an administrator gives you an extra role to fix one missing button, you may quietly gain access to a lot more than that button. It is reasonable to ask "does this role give me anything else?" when you request one.

Example Petra holds "Support Agent", which lets her see only tickets assigned to her team. For two weeks she covers for a colleague and is given "Support Supervisor" as well, which lets her see every ticket. During those two weeks she sees all tickets — the narrower rule from her first role does not hold the wider one back. When the supervisor role is removed, her list shrinks to her team again.

A Role Can Bring A Second Sign-In Step

A role can carry a requirement for two-factor sign-in. If any one of your roles requires it, you get it — the strictest requirement across all your roles applies. So gaining a role can add a second step to your next sign-in without anything else about your account changing.

See Signing In for what that second step looks like.

Role Changes Take Effect At Your Next Sign-In

There is an asymmetry that causes a lot of confusion, and it is worth getting straight:

• When an administrator changes the rules attached to a role you already hold, the change applies immediately. Reload the screen and the new column or button is there.
• When an administrator adds or removes a role on your account, nothing changes until you sign out and sign in again. Your roles are read from your current session.

So "the administrator changed something and it worked instantly" and "the administrator changed my roles and nothing happened" are both normal. If you have been given a new role, sign out and back in before reporting that it did not work.

An administrator can also force this by signing you out from their side. If that happens you will see "Your login has expired. Please sign in again." on your next click; sign in again and the new roles apply.

Groups

What A Group Is

A group is a set of people. In most applications it mirrors an organizational unit — "Prague Office", "Field Service", "Accounts Payable". Every person is normally in one group.

What A Group Actually Does

A group carries no permissions of its own. What it does is:

• Decide where you land. Your group can have a home screen — a particular module — that its members open when they sign in or click the home link, unless you have a personal one of your own. See The Application Window.
• Provide a starting dashboard. Your group can have a default dashboard layout, which is what you see until you personalize your own. See Dashboard And Widgets.
• Serve as a handle for targeting data. Because "which group is this person in?" is a fact the application knows about you, it can be used to shape what a screen shows — "records belonging to my group" — without anyone having to build a separate role per team.

That third point is the one people mix up with permissions. The group does not grant anything; it is used as a value in a rule that a role carries.

Example A field service application has one role, "Technician", held by everyone in the field, and two groups, "North Region" and "South Region". The Technician role's rule for work orders says "show the records whose region matches the signed-in person's group." One role, two regions, and nobody sees the other region's jobs. Moving a technician from South to North changes their list the next time they load it — no role change is involved.

Role Or Group — Which Is It?

The Five Questions Behind Every Screen

Every time you open something, the application works through a series of checks. Thinking of them as five questions makes it much easier to describe what is missing.

1. Can You Get Into This Area At All?

The first question is about whole areas of the application rather than data: the navigation panel itself, the dashboard, the search box, the notification bell, your own profile page, exporting to a spreadsheet, the trash, and similar application-wide capabilities.

Each of these is a separate yes. It is entirely possible to have a rich, working application with no search box in the top bar, because the search capability was never granted to your role.

What you observe when the answer is no:

• The control is absent, not disabled. No search box, no bell, no dashboard entry — nothing is grayed out, there is no message, and there is no hint that something is missing.
• A module you may not open is absent from the navigation. If no module at all is available to you, you get a page reading "No modules available" and "There are currently no modules available for use. Please check your permissions or contact your system administrator."
• If you reach a page you may not open — usually through a link someone sent you — you are bounced back to the sign-in screen with the message "You do not have sufficient privileges to access this page."

Example Two people work on the same purchase orders. Jan has the trash capability, so his navigation shows a Trash entry. Eva does not, so she has no Trash entry at all, and if she deletes a purchase order she has to ask someone else to look for it. Whether anything is there to find is a separate question: in most applications a delete is permanent and the trash holds nothing. See Deleting Records And The Trash.

2. May You Work With This Kind Of Record?

The second question is about a kind of record — invoices, projects, applicants — as a category. There are separate answers for:

• seeing a list of them,
• opening one and reading it,
• adding a new one,
• changing an existing one,
• deleting one.

These are genuinely independent. Being able to open an invoice does not imply being able to edit it; being able to edit one does not imply being able to create one.

What you observe when the answer is no:

• A denied list looks like an empty list. The screen renders normally — toolbar, filters, paging — and shows the view's own no-data message, by default "No data match the query." It does not say "you are not allowed." This is the single most misread symptom in the whole application.
• No add button. The button that creates a new record is only drawn if you may create that kind of record.
• Opening a record you may not read behaves differently depending on how you got there. In a pop-up window you get a panel titled "Object unreachable" with the heading "Object not found" and the text "The object you are trying to reach is not available. It might have been deleted or you do not have rights to display it." On a full page you are quietly returned to the list with no message at all.
• Note that the pop-up wording covers two different causes — genuinely deleted, and not permitted — and does not tell you which.

Example A recruiter opens the Applicants list and sees candidates fine. She opens the linked Job Openings list from the menu and it is empty, with "No data match the query." She assumes the openings were never created. In fact her role was never granted the right to list job openings; her colleague's identical screen shows fourteen of them.

3. Which Individual Records May You See?

This is the layer that surprises people most. A permission does not have to be a plain yes. It can be yes, but only for records that match a condition — and the condition can refer to you.

That is how a screen can be built to show you:

• only the records you own or were assigned,
• only the records belonging to your team, group, region or branch,
• only records in a certain state — approved, published, closed, not archived,
• any combination of those.

The list screen itself is identical for everyone. The rows are not.

The same scoping applies when you open a single record directly, and when you try to change or delete one. Opening a record outside your scope behaves as though the record does not exist rather than telling you that you are not allowed. Saving or deleting one is refused outright: the save fails and you get the application's generic error dialog, which does not name permissions as the cause. See When Something Goes Wrong.

Two knock-on effects are worth knowing:

• Counts and totals reflect your scope. If a list says 42 records and a colleague's says 380, neither number is wrong. Any calculation on that list is computed over what you may see.
• Links to records outside your scope come back empty. If an order points at a customer you may not see, the customer field resolves to nothing — and because fields with no value are hidden by default, the field usually disappears from the screen entirely. It reads as missing data rather than as restricted data.

Example An insurance application scopes claims by handler. Marek opens Claims and sees 23 rows, all his. His team leader opens the same screen and sees 190. The auditor, whose role is scoped to state rather than person, sees only the 14 claims currently in "Closed — pending review", across everybody. Three people, one screen, three legitimate results.

Example Marek is sent a link to claim 4471, which belongs to a colleague. Clicking it in a pop-up window gives him "Object not found." Opening the same link as a full page returns him to the claims list with no explanation. Neither response confirms that the claim exists — which is deliberate.

4. Which Fields May You See, And Which May You Change?

The fourth question is asked per field. There are separate answers for seeing a field, filling it in when creating a record, and changing it afterwards. So a field can be:

• visible and editable — the normal case,
• visible but read-only — you can read the agreed discount, but not alter it,
• not visible at all — the field is absent from the record.

A field you may not see is absent everywhere, not only on the record. It disappears from the record detail, from the add and edit forms, from the column picker, from the filter builder, from grouping and from calculations. You cannot filter or sort by a field you cannot see, and search results will not show text that matched inside it. See Finding Things And Search.

Field visibility can itself be conditional on the record, exactly like row visibility. The same field may be present on one record and absent on the next one in the same list.

There is a lookalike worth separating out: a field with no value is hidden on the record detail by default. So an absent field means either "you are not allowed to see it" or "it is empty" — and the screen looks identical either way. If a colleague can see it and you cannot, it is a permission. If nobody can see it, it may have no value.

Example On the Employee record, the "Salary" and "Bank account" fields exist for the HR role only. A team leader opening the same employee sees name, position, start date and manager — no salary field, no gap, no message. When the leader exports the list to a spreadsheet, those columns are not in the file either.

Example On a Purchase Order, the "Approved amount" field is visible to a buyer only once the order has reached the "Approved" state. On draft orders it is absent, on approved orders it is there. The buyer's first assumption is that the field was added recently; in fact it appears per record.

5. Which Buttons And Actions Are Available To You?

The last question is asked per button. Every action is evaluated individually: the built-in ones for editing, duplicating and deleting a record, and any custom action your administrator has added, such as "Send for approval" or "Generate contract". The built-in ones can be renamed, reordered and re-iconed per application, so their captions are not fixed.

The important detail: denied actions are removed, not disabled. You never see a grayed-out "Approve" button that hints someone else can press it. The menu is shorter. If you are allowed nothing on a record, the whole actions menu is absent from its detail screen.

Like row and field visibility, an action can be conditional on the record. "Approve" may be available on an order that is waiting for approval, and gone on the same screen for the order below it that is already approved.

One more consequence: the menu you get by right-clicking a row on a table is fetched fresh each time you open it. That is why there is a brief pause before it appears, and why its contents can change between two openings of the same row if the record's data changed in between.

One built-in action is granted separately from ordinary editing: "Edit (ignore required)". It opens the usual edit form with the mandatory-field check relaxed, so a record can be saved half filled — useful when data arrives in stages and blocking on a missing field would stop the work. Because it lets incomplete records into the system, your administrator has to hand it out deliberately, per kind of record and per role; it is never included in a blanket "everything" grant. It also never widens what you may edit: without ordinary edit rights on a record, the relaxed form is not offered either.

Actions can also legitimately do more than you could do by hand. An administrator can build a button that runs with elevated rights — for example, a "Submit expense claim" button that also writes a record in a finance area you cannot see. This is intended behavior, not a leak.

For what the buttons under a list do, see Action Buttons And Exporting.

And Tabs, Too

Record detail screens often have tabs — an overview, a change history, related lists. Each tab is its own yes, and can be conditional on the record. So a tab can be present on one project and absent on another, for the same person. See Record Detail Screens.

Two Colleagues, One Screen

Put the five questions together and the practical outcome is this: two people can open the same screen at the same moment and see different rows, different columns and different buttons — and both screens are correct.

Worked example: the Orders list

The application has one Orders list screen. Three people open it on the same Tuesday morning.

	Dana (Sales Rep)	Tomáš (Sales Manager)	Lucie (Finance)
Rows	18 — her own	240 — the whole team	63 — invoiced orders only
Columns	Customer, Value, Stage	Customer, Value, Stage, Owner	Customer, Value, Invoice no., Payment status
Add button	Yes	Yes	No
Row actions	Edit	Edit, Delete, Reassign	Edit only on unpaid orders
Total shown	18 orders, 240k	240 orders, 3.1M	63 orders, 890k

Nothing here is a bug. Dana's role is scoped to her own orders; Tomáš's is not. Lucie's role never received the fields about sales stage, and never received permission to create orders. The totals differ because each total is calculated over the rows that person may see.

The corollary is a habit worth adopting: when comparing screens with a colleague, do not assume you are looking at the same thing. Compare record by record, not count by count.

Licensed Capabilities

Roles are not the only reason something can be missing. Some whole areas are switched on per application rather than per role — for example the trash, the file repository, the event log, the translation tools and the AI assistant. If your application does not have one of these enabled, the corresponding menu entry is not shown.

Two things follow:

• There is no upgrade prompt. An unavailable area is absent, with no message explaining why. From your side it is indistinguishable from a missing permission.
• An administrator may see something you cannot. The most privileged administrator account bypasses this check entirely, so it sees these areas whether or not the application has them switched on for everyone else. "It works on my screen" from an administrator is therefore not proof that it will work on yours.

If a capability you have been told about is missing, it is worth asking whether it is a permission or whether the application has that area enabled at all. Your administrator can tell the two apart in seconds; you cannot.

What You Cannot Do Yourself

This is a short list, and it is absolute.

• You cannot grant yourself access. There is no request button, no "ask for access" flow, and no temporary self-service elevation anywhere in the application. Access is changed by an administrator.
• You cannot see the rules. The screens where roles and permissions are configured are part of the administration area, which ordinary business roles do not reach. You cannot look up why something is hidden from you.
• You usually cannot see who else has access. The screen listing people and their roles is itself permission-gated, and most business users cannot open it. If your role does happen to reach it, other people's roles are shown there as an ordinary column.
• You cannot tell "denied" from "empty" on your own. As covered above, both usually look like an empty list. Only a comparison with a colleague, or an administrator's check, resolves it.

What you can do is describe the situation well. See Why Your Screen Differs for the checklist.

Privacy: What To Assume

Take this as the working rule: anything you can see, colleagues holding the same role and falling in the same scope can see too. Permissions are defined per role, not per person, so you are never the only holder of a view unless you are the only holder of that role.

Specifically:

• Comments are not private. A comment on a record is visible to everyone who can open that record and has permission to view its comments. There is no private comment, no direct message and no "visible to managers only" option. Mentioning a colleague notifies them and makes the record show up in their own mentions list. See Comments And Mentions.
• Your changes are attributable. Where the change history is switched on for a kind of record, each change is recorded with who made it and when, and colleagues who can open that record's history can read it.
• Notes typed into fields are ordinary field values. A "remarks" or "internal note" field is only as restricted as its field permission — which may well be "everyone who can open the record."
• Attachments follow the record. A file uploaded to a record is visible to anyone who can see that record and that field.
• Two things really are yours alone: a saved view you marked private, and a private tag you created. Neither is visible to colleagues. Treat them as personal convenience, not as a way to conceal information — the underlying records remain governed by everything above. See Saved Views And Queries.

If something genuinely must not be seen by a group of colleagues, that has to be arranged as a permission by your administrator. Do not rely on burying it in a comment or an unlabeled field.

Tips And Gotchas

• Empty is the normal face of "not allowed." A list denied to you renders as a working, empty list. Before concluding that data is missing, check with someone whose role is broader.
• Sign out and back in after a role change. New roles are picked up at sign-in. Changes to what an existing role may do apply immediately.
• Adding a role never removes anything. If access got narrower, a role was removed, or the underlying data changed so that a conditional rule no longer matches.
• A missing menu entry has three possible causes: your role, the capability not being enabled for your application, or the area having been switched off entirely by an administrator. You cannot distinguish them from the outside.
• The same record can behave differently over time. Because rules can depend on a record's data, changing a record's state can make fields and buttons appear or disappear. That is the rule working, not a glitch.
• Do not fix access by borrowing an account. Signing in as a colleague to check something defeats the change history and is generally against policy. Ask for the permission instead.
• Row-level rules cost time. Screens whose access depends on a per-record condition are measurably slower on long lists than screens with a plain grant. If a particular list is slow, mention that to your administrator — it is useful information.

What To Ask Your Administrator For

Phrase the request in terms of the five questions, because that is how the rules are organized.

Always include the exact screen, one record where it fails, one record where it works, the exact wording of any message you saw, and the name of a colleague for whom it works. That combination is what lets an administrator find the answer without guessing.

For the full catalog of things only an administrator can change, see What To Ask Your Administrator For.

Related Chapters

• Why Your Screen Differs
• What To Ask Your Administrator For
• How Your Application Works
• Signing In
• Comments And Mentions