Roles

A role is essentially a named group of permissions which can be assigned to a user or service account. Using roles you can easily manage access control, data permissions, and available functionality across a solution. A user can be assigned multiple roles. In that case, the sum of a user's permissions determines their access.

There are two categories of roles:

• Built-in roles which are part of the platform and cannot be removed.

• Custom roles which you can create and customize for the types of users your solution requires.

Roles are available in the condition editor so you can build conditions in your UI and actions to adjust functionality based on the current user's role.

Built-in roles

As a developer in Appfarm Create, you'll typically have one of the three built-in roles. They are:

• Owners

• Maintainers

• Developers

Owners have access to everything in Appfarm Create and the Development environment, while Maintainers and Developers have more restricted access to modifying users and roles. The Developers role is also restricted from deploying apps and making configuration changes.

Built-in roles get access to all apps and services, as well as full object class permissions, as they are created. These permissions can be withdrawn if desired. All other permissions are fixed.

Even with a built-in role you will almost always have at least one custom role in addition, for access to client apps outside of development.

Good to know

The built-in roles do not have access to Test, Staging, or Production. To access a client app in these environments you must have a custom role with the necessary permissions.

Custom roles

Custom roles allow you to define your own roles based on your solution's requirements. Then, each role can be assigned granular permissions that determines their access. A custom role does not have access to Appfarm Create unless it is explicitly granted.

Some common example roles include:

• An Administrator role which has permissions to create and modify users in the app

• A Viewer role which only has read-only access to data.

• An Integration role with access to services open to external systems.

• A Public role for providing unauthenticated access to an app.

• A Tester role which grants access to the Test environment.

Best practice

Set up custom roles early in development, create test users with those roles, and use those to test as you build. Following this approach will help ensure you create a secure solution with roles and access levels ready for production.

Properties

Property	Description
Name	A unique name for the role.
Description	A longer description of the role. For your own reference.
Client Login Access for Role	The environments that they role should have access to. This permission can also be granted under Permissions > Login Access, including access to the Development environment if that is required.