Using Flexxible|SUITE Roles and Users

Managing visibility and permissions. Users and groups. Roles. Allowed tenants.


This article explains how the new roles work and the features of the functionality. This action is only allowed for users with the administrator role.

Flexxible|SUITE allows you to import any user or group included in the domain. To do so, please access the web console available to manage the environment.


VDI OS Roles

The console includes a series of basic roles. These roles can change based on the type of implementation. The main purpose of the roles is to limit user visibility and their access level to the console.

You can search for "VDI OS Roles" in the Search box located in the left-side menu and then click on any of the Roles.

The new role configuration screen has two sections. The first one defines the role name and whether the role belongs to the administrator group or not.

Remember: the role checked as "is administrative" inherits the administrative role actions and type permissions (i.e. full control), independently of the current actions and type permissions.

 The second section is only visible to users that already belong to an administrator group. This contains the following tabs:

  • Actions. All actions ( shown as buttons) are available in Flexxible|SUITE.
  • Type permission. These are the effective permissions for a user within that role that applies to a particular object like reading, write, browse, etc.
  • VDIUser are the users that belong to that role


Can export

The "Can export" check box in a Role's detail view enables the new "Export to" option that allows exporting to Excel the lists in Flexxible|SUITE with the visible columns.

  • The administrator role can export by default
  • When cloning a role, it also clones the value "Can Export".



This section describes each tab on the role screen, as well as the actions that can be performed.

Actions tab

This tab helps to configure the visibility of the actions that can be run in Flexxible|SUITE. Actions are grouped by concepts. The image below shows all actions that can be performed for objects in the Active Directory, such as assigning a flag, adding additional services, creating a new object, etc.

You can manage the action visibility that can be applied to any entity (such as buttons, functions, menu options, etc.). Two values are available:

  1. True, the action is visible.
  2. False, the action is not visible.


If you select one of the options and click Change action visibility, The visibility of the action will revert: if the action was displayed before, it is now not displayed to users who belong to that role and vice versa.


To reset the visibility of actions to the default setting, there is a "Reset actions visibility" button that will return the visibility of actions to the initial setting when VDI Manager OS was installed.


Type permissions tab

This tab defines the effective permissions for users who belong to this role. 

Once we have established the visibility level throughout the Actions, by configuring the Type Permissions, it is possible to establish the interaction level between the users and the entity associated with the desired permissions. This functionality has five configuration levels:

  1. Read, allows reading de content of this entities values.
  2. Write, allows modification of entities values
  3. Create, allows creating new entities.
  4. Delete, allows deleting entities
  5. Navigate, allows us to navigate in a particular entity. Therefore the visibility in such an entity is limited.

The following image shows that users who belong to this role can read, write, create, delete, and navigate Alert-type objects..


To change a value in this table, just click above the value you want to edit and save changes with the Save changes option.

In SWS implementations, by default, the domain administrator (including client and infrastructure), has full permissions. In SWS-QC  the infrastructure administrator has total permissions for full and mixed deployment and the client domain administrator for full integration.

Permissions by Role

Flexxible|SUITE deploys the following Roles:

  • Custom
  • Commercial/Sales
  • Wholesaler
  • Tenant
  • Partner
  • Administrator

Below, we will detail each Role


The Custom role can access the following sections:


  • Sessions: Within sessions, you can perform the following actions:
    • Log off
    • Notify User(s)


  • Dashboard UX: Visibility within your own tenant


  • Jobs: You can access the Jobs list and the job detail. 
    • In the job list, you can cancel and notify the jobs.
    • Within the detail, you can see the cmdlets that have been executed in the same job.


The Commercial role has access to the sections of the Custom role plus


  •  My Company: View of the main tenant
  • Tenants: View all tenants where you have visibility. Within these you have visibility permissions in all sections and can perform the following actions depending on the section:
    • Users
      • Delete user
      • Apply the change of password at the next login
      • Remove user lockout
      • The different assignments of Desktops, SDIs, and applications
      • Assigning role
    • Templates
      • Execute power actions
      • Run Refresh VM Info
    • Customization: You can perform all the actions
    • Desktops: You can perform all actions
    • Server
      • Perform power actions on the server
      • Start remote administration
    • Application server: You can perform all actions
    • Connection info: Configure the export.



The wholesaler role can perform the same actions as the Commercial role and also


  • Desktops: You can perform all actions within this section.
  • Policies by user
    • Reading permissions in all sections
    • In the Desktops section, you can perform Power Actions and Refresh VM Info


  • Servers
    • Reading permission in view and details
    • All actions 
  • Hosting units
    • Reading permission in view and details


Reading permission on the following sections and their details

  • Usage log
  • Connection logs
  • Event logs
  • Alerts
  • Alert subscriptions
  • Alert notification profiles
  • Alert definitions



The Tenant role can perform all the actions of the Wholesaler role except the Usage Log. It also has new permissions such as:


  • Tenant
    • User creation
    • User import



The Partner role has all the permissions of the Tenant role and also


  • Templates: Creation of templates and creation "from existing template"
  • Templates: Shared Templates Implementation



The administrator role has all the read and write permissions within the SUITE.


Roles will always be subject to the scope of the tenants you have authorized.




Examples of permission levels for some roles in a multitenant implementation:

ADMINISTRATOR Full administration


How to create a new type permission

To create new type permission, you must click on the New button on the type permissions list.


On Flexxible|SUITE, each data type has defined type permission.  You must select the data type in the target type dropdown and check the desired permissions.


Then the new type permission is defined.


Please, remember to save the role to apply changes.


VDIUser tab

This tab shows the users belonging to this group.


This tab offers two actions: Link a new user to the role or Unlink a user from the role. If you click either option, a pop-up window will appear where you can select the user and link or unlink, depending on the action you selected.


How to create a new VDI OS Role

To create a new VDI OS Role, you must duplicate an existing role. To do this, you must select the desired role and click on the clone button in the role detail.


This action inherits actions and type permissions. Now, you can change their values.


Note: The administrator role can't be cloned.


How to delete a VDI OS Role

To delete a role, you must select the desired role and confirm.


You must consider the default roles can't be deleted.


Access Management to VDI OS Manager

During an environment deployment, it is possible to assign access to new users and groups included in the Active Directory of any domain integrated into the console. To do this, in the SWS implementations:


  1. Click on "VDI OS Users and Groups"
  2. Click on New:

  1. Select the account type: User or Group
  2. Enter the account name or the Group name
  3. Select the tenant associated with the selected user
  4. Activate the user


The use of primary groups is not supported.


Click on "Link" to assign a role to the new User/Group:

  1. Select the desired role
  2. Click "OK"

If the user is associated with a partner or a wholesaler in a multitenant implementation, you can limit the visibility of such user to only the tenants specified in this area using the Allowed Tenants functionality as shown below:


To do this, you have to "Link" the tenants you want to be visible for the user.


How to grant User Access from the "Tenant" View, or from the "My Company" menu option

Flexxible|SUITE Platinum, Platinum Multitenant include the "Tenant"  and "My Company" application view whereas Enterprise implementation only include the "My Company" application view. In any of these views, you can grant  any of the users that belongs to a particular tenant with access to the console. To do this,  you should select a specific "Tenant" and click on the Users Tab


Then, you should click on the user you want to grant access to the console:

Once the VDIManager access option is checked, the user will have the corresponding access, depending on its multitenant level. In other words:

  • If the user is assigned at Tenant level, it will have tenant access.
  • If the user is assigned at Partner level (tenant default), it will have partner access.
  • if the user is assigned at Wholesaler level, it will have "Wholesaler" access.

If we need to increase or decrease the predefined access levels, we need to go to the VDI OS users and Groups session:


Then we go to the desired user.


Then, we can add or remove the user roles in the Roles section.

If a user has more than one role, it is important to know that the most restrictive user role will always become the predominant one.


The following image shows the result after adding a user to the role.


Was this article helpful?