OutSystems allows to define the permissions an IT user has, by assigning them roles. When creating a new user, you need to assign a default role. This role defines the permissions the user has in each environment of your infrastructure.
By default, the role permissions apply to all applications. But you can then fine-tune the permissions for each application the user works on. Learn more about permission levels.
For example, you can grant a user permissions to list the applications on the Development environment. Then you can give the user permissions to change and deploy the Vacations application, both on Development and Quality Assurance. This allows the user to deploy the Vacations application from Development to Quality Assurance. But is also disallows the user to make changes to any other application.
To reference elements in other applications, the user needs at least reuse and monitor permissions for those applications or on the default role.
For system elements, the user needs at least reuse and monitor permissions in the default role. The exception is system entities. The rational is that system entities include vital information for the platform's proper running. So the user needs to have at least change and deploy permissions in the default role to create these references.
Simple Security Policy for Small Teams
By default, OutSystems has two roles that allow you to implement a simple security policy:
- Developer: allows deploying to the Development environment, open applications on Quality Assurance, and list applications on Production;
- Administrator: allows deploying applications to all environments of the infrastructure and manage IT users, security, and environments.
With these roles you can make the following example configuration:
- Allow all developers to create and change applications on the Development environment.
- Have a release manager with the Administrator role. The release manager can deploy the applications to Quality Assurance and Production.
Simple Security Policy for Large Teams
If the two default roles are not enough for your security policies, then create your own roles. Having more roles gives you more flexibility in controlling the permission levels of IT users. Learn how to create new IT roles.
In this example, we have four roles, with increasing privileges:
- Tester: Can only open applications on Quality Assurance. This role cannot change anything;
- External Developer: Can only change and deploy applications on the Development environment;
- Developer: Can change applications on Development and deploy them to Quality Assurance;
- Administrator: Can deploy applications to all environments, and manage users, security, and environments.
Enterprise-grade Security Policies
To enforce stricter security policies, you can define IT user permissions for a specific application.
For this, assign IT users with a default role that has few privileges. Then, grant them access to specific applications. Do this by assigning them a role with higher permissions for each application.
In this example, Brooklyn's default role allows her to list the applications on Development. But for the Vacations application we assigned her the Developer role. This allows her to change the Vacations application on Development and nothing else. Learn how to grant IT permissions for specific applications.
Managing the permission each IT user has on each application can be difficult. This is even more complex when you have lots of applications or users. To help solve this, OutSystems allows you to define Teams.
A Team is a group of IT users that work on several related applications. When you add a user to a team, you can define the permissions the user has for those applications. You do this by assigning the user a role specific to the applications in the team.
This allows you to specify the permissions a user has for several applications at a time. You do not have to grant those permissions for each individual application. Learn how to create an IT team.
In this example, John's default role only allows him to list applications on Development. But John's role in the Customer Portal team allows him to change and deploy all applications in this team. These applications are: Customer Portal, Cases, and CRM Services.