Roles
Last updated
Was this helpful?
Last updated
Was this helpful?
A role is essentially a named group of which can be assigned to a or . 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:
which are part of the platform and cannot be removed.
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.
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 , while Maintainers and Developers have more restricted access to modifying and roles. The Developers role is also restricted from 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.
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.
Name
A unique name for the role.
Description
A longer description of the role. For your own reference.
Client Login Access for Role
The that they role should have access to. This can also be granted under Permissions > Login Access, including access to the Development environment if that is required.