You can restrict access to:

• Platform modules and applications:
  • "Access Control" module
  • "Orchestrator" module
  • ROBIN Studio Enterprise application
  • ROBIN Player Enterprise  application
• Objects added to the platform's remote storage:
  
  • robot projects (the user publishes them to the repository himself via ROBIN Studio)

  • finished robots (the user publishes them to the repository via ROBIN Studio).
    machines - server or personal computer (the ROBIN Agent automatically transfers the machine data to the repository as soon as the client part of the platform is installed on the machine).

  • robot start schedules (added to the storage when the user creates them via the Orchestrator module interface).

Users access rights to components and objects are delimited by tenants.

Tenants are some kind of multigroups, each of which has its own sets of objects, users and roles.

Each tenant has its own settings, access rights, and other aspects of process management. This provides data isolation and access control between different groups of users or projects.

When entering the web-interface of the platform or its desktop application, it is necessary to select the tennant within which the work will be performed. The selected tennant will depend on:

• Which objects are available to the user. The user always sees only those objects that are added to the tenant under which he/she has logged in.
• What operations the user can perform on the objects. The available operations are determined by the role(s) the user has in the selected tenant.
• The accessibility of the component itself. Access to the component is also determined by the user's role. If the user does not have a role in the tenant that allows the user to work with the component, it will be hidden (web interface) or the system as a whole will deny access (desktop applications).

A user cannot log in without a tenant, so the user must have access to at least one tenant to work with modules and applications. To gain access to a tenant, a user must be added to it, and necessarily with one or more roles created in that tenant. A user can be added to several tenants at once. The user can have different roles in each tenant. But even with access to several tenants, a user can log in to the system only within one tenant. When deploying the platform, a single tenant is always created, which can be used to start working with the platform.

Also within a single tenant, you can more accurately differentiate user access to tenant objects by grouping them. The principles of grouping are as follows:

1. The administrator creates a group of objects in the tenant. Transfer objects to the group that not all tenant users can work with.
2. Creates a user group in the same tenant. Adds to the group only those users who are allowed to work with objects from the 1st point.
3. Gives the user group rights to the group of objects.
4. Users who are added to the tenant but not added to the group have access only to those tenant objects that are not allocated to the object group.
5. Users who are added to the tenant and additionally added to the group have access both to those tenant objects that are not allocated to the group and to the objects added to the object group.

By default, groups do not exist in tenant, they must be created separately (if necessary).

Limitations of the current release.