Privileges and permissions in Jitterbit App Builder
Overview
App Builder's authorization model rests on two related but distinct concepts. A privilege determines whether a group can reach an application or data source at all, while a permission determines what that group's members can actually do with the data once they're in. Every user's access is really just the sum of the privileges and permissions granted to the groups they belong to.
This page explains both halves of that model in turn:
- Privileges: Learn how administrators grant a group access to an application or data source, and how that access relates between the two.
- Permissions: Learn how roles grant specific actions on data, and how that in turn shapes which pages, menu links, and page controls a user can see.
Privileges
A privilege is a yes-or-no grant that controls whether a group has access to a certain application or data source at all. Administrators grant privileges directly to groups, never to individual users, so every member of a group shares whatever privileges the group has. This section covers how privileges work for groups in general, and the specific relationship between an application's privilege and the privileges of the data sources it uses.
Groups and privileges
Groups organize users so administrators can manage their access collectively, rather than one user at a time. To give a group access to part of App Builder, a security administrator grants it privilege to a specific application or data source, using the steps in Grant a group access to an application or data source.
Granting a group privilege to an application normally extends that privilege to the data sources the application uses. This extension only flows in one direction. See Application authorization for the exceptions to this rule.
Application authorization
An application typically uses one or more data sources to store and retrieve its records. When a security administrator grants a group privilege to an application, App Builder automatically extends that privilege to every data source the application references, so the group doesn't need a second, separate grant to use the application normally.
Note
Some features are an exception to this extension, requiring a group to have explicit privilege to a data source even though it already has privilege to an application that uses it. For example, Conversational AI requires explicit privilege to a registered agent's data source before a group's members can chat with that agent.
The reverse isn't true, though: granting a group privilege to a data source doesn't grant it privilege to any application that happens to use that data source. Privilege to a data source only lets a group work with that data source directly, for example through a report or an integration, not through any particular application.
For example, suppose a customer data source is used by two different applications, Customer Reports and Customer Lookup. A group granted privilege to Customer Reports can use the customer data source through that application, but the same group cannot open Customer Lookup unless it's granted privilege to that application separately, even though both applications rely on the same data.
Note
Having privilege to a data source is necessary to use it, but it isn't always sufficient. If the data source defines roles, the group also needs to be a member of one or more of those roles; see Data source authorization for details.
Permissions
Once a group has privilege to a data source, permissions determine exactly what its members can do with the data objects in it, such as querying, inserting, updating, or deleting records. Permissions are granted through roles, and App Builder also uses them to decide which pages, menu links, and page controls a user can actually see. This section covers how roles and permissions work, and how they shape a user's experience of an application's pages.
Data source authorization
Not every data source needs the same level of granularity. A data source is secured using one of two authorization models, depending on whether it defines any roles:
| Model | Description |
|---|---|
| Data source authorization | If a data source doesn't define any roles, privilege alone is enough: any group with privilege to the data source has full permission to all of its data objects. |
| Roles-based authorization | If a data source defines one or more roles, privilege to the data source isn't enough on its own. A security administrator must also add the group to one or more of the data source's roles, as described in Roles and permissions, to determine exactly which actions its members can take. |
Roles and permissions
A role is a combination of permissions defined on a data source, such as Contributor or Viewer. For data sources that use roles-based authorization, a role is how permissions actually get granted: a security administrator adds a group to one or more roles, and every member of that group receives all the permissions those roles include.
Permissions themselves are the most specific unit of access control in App Builder. Each one grants a single kind of action on a data object:
| Permission | Description |
|---|---|
| Read | Allows users to query the data object. |
| Insert | Allows users to insert records into the data object. |
| Update | Allows users to update records in the data object and execute user-defined events. |
| Delete | Allows users to delete records from the data object. |
A single role can combine several of these permissions to match how a group of users should work with the data. For example, a Contributor role might grant Insert and Update permissions so its members can add and edit records, while a Viewer role might grant only Read permission so its members can look but not touch.
Note
If role changes don't seem to apply to users, try flushing the cache from the System Maintenance options:
- Go to IDE > Additional Settings.
- Select System Maintenance in the Manage panel.
- Click Flush Cache.
Page authorization
Users are authorized to see and interact with specific pages based on their access to data objects. This is because App Builder doesn't secure pages directly; instead, it secures the data objects a page is built on, and derives the user's access to the page itself from their permissions to those objects. There are types of panels (such as Grid, Form, and Chart) and controls (such as List) that are bound to data objects, and are therefore subject to this underlying permission check.
A user has permission to a page if and only if they have Read access to every data object the page uses. This rule applies even to a page built directly on a data source, such as a file upload page built on a local file system: the user's group needs explicit privilege to that data source, separate from any privilege it has through an application, before the page becomes accessible.
If a user requests a page they don't have permission for, they receive an "Access Denied" error. In practice, this is uncommon, since App Builder hides or disables links and menu entries to pages a user can't access in the first place; it mainly happens if security is misconfigured, or if a user navigates directly to a page's URL, for example by clicking a stale link in an email.
App Builder adjusts menu links, page links, and page controls based on a user's permissions.
Menu links
When constructing menu links, App Builder checks whether the user has Read access to each link's target page. If they do, the link appears in the menu; otherwise, App Builder hides it, so users never see menu entries for pages they can't open.
Page links
Similarly, when rendering a page, App Builder checks whether the user has Read access to each embedded page link's target page. If they do, the page renders as designed. Otherwise, App Builder adjusts the page as follows:
- Hides the Grid panel's link icon (chevron or popup) and disables its double-click action.
- Hides Grid panel columns defined by controls that aren't data-bound (such as Buttons).
- Renders data-bound controls within Grid or Form panels (such as Text or List controls) un-clickable.
Page controls
Beyond simply hiding a link, App Builder also hides or disables the specific controls a page offers, based on which permissions the user's group has for the underlying data object:
| Access Right | Affects |
|---|---|
| Insert | Hides the Grid panel's Add button. |
| Update |
|
| Delete |
|