User management is an extensive set of features enabling you to provide your colleagues and external contacts access to your machines. It allows you to specify exactly which machines the user has access to and also what the user can and cannot do at those machines. This enables you to cater access and permissions to each individual user. At the same time, the use of roles and groups allows for scalability in how you use your user management.

For frequently asked questions, see User management FAQ.

• User management explained
• User management guide
  • Walkthrough
  • Additional examples

User management explained

The user management in the IXON Cloud consists of 2 core elements:

The below video explains the user management in a more visual manner.

User management guide

There are countless ways you can set up your user management. In this chapter we'll use a simple example to help you set up your user management as well as provide additional examples.

• Walkthrough
• Additional examples

Walkthrough

The example use case we'll use in this walkthrough provides a good starting point for most users and also helps you to better understand the user management.

Groups

A proper group structure enables you to maintain a clear overview, make it easier to find your devices, and makes it more scalable and easier to grant other users access to (a group of) devices or manage other users (within their group).

Think about your own company and access structure. Do you have partners that you work with on various projects? Do you perhaps have customers that would like limited remote access? These are elements that determine your group structure.

1. Go to Admin > Groups.
2. In the left menu, hover over Groups, open More options, and select Manage.
   • If you have the module Hierarchical user groups, you can manage your group types directly in the bottom left menu. Check your modules at Admin > Licenses. To obtain this module, contact your IXON account manager or IXON distributor.
3. Create your Group types. Below is an example from the example use case.
   Example use case - Group types

   • Partner / Integrator
   • Customer
4. In the left menu, under Groups, add your groups to each group type. Below is an example from the example use case.
   • If you have the module Hierarchical user groups, click on Groups to manage all groups and the group hierarchy. Hover over the company name, open More options, and select Add new to add groups. You can also create groups within other groups or draggroups into other groups to create a hierarchy of subgroups.
   Example use case - Groups

   • Partner / Integrator
     • Propack Engineering
     • Freelance Software Engineer
   • Customer
     • Customer X
     • Customer Y

Your group structure is now set up, but is not used yet. There are no devices and no users in these groups yet. Users will be invited later. Devices can already be added to your groups:

5. Go to Fleet Manager > Devices and click on one of your device names.
6. In the left menu, go to Info.
7. Under Groups, assign the device to the groups following the example below, or select your own.
   Example use case - Assign groups

   • If you work(ed) together with a partner on a machine, assign that device to the correct Partner / Integrator group.
   • Also assign it to the correct Customer group.
8. Repeat these steps for each of your devices.

Access categories

Access categories are a special type of permission that allow a user to use all services (VPN, VNC, and HTTP), view all pages, and receive all notifications (alarms) that are linked to a particular access category. In other words, it determines what services and functions a user can use on the devices that they have access to.

Below is a practical example of the use and effect of access categories.

Practical example

This example is not used in the walkthrough. It's merely to illustrate and explain access categories.

Example
Let's say you have 2 devices with both a VPN and VNC service. Also assume that you created 2 access categories ("VPN" and "VNC") and assigned them to their respective services at both devices.

• VPN service (assigned the "VPN"-access category)
• VNC service (assigned the "VNC"-access category)

Graphically, it'd look like this:

If you then invite a user to device B with permission to access category "VNC", what do they see and what can they do? This:

On the device that they have access to (device B), they can use the services that they have been granted permission for (VNC). They will not see device A, because you only gave access to device B. As a result, this user also cannot access the VNC service of device A, even though it is assigned the same "VNC" access category.

Think about how functional access is arranged in your company. Is everyone allowed to access every service on the device(s) that they have access to? Then you're fine with just having a single access category. If that is not the case, then you'll need to create separate access categories for each of those services.

1. Go to Admin > Access categories and add access categories from the example below, or create your own.
   Example use case - Access categories

   • No access (make this the default access category)*
   • VPN (type: Service)
   • VNC (type: Service)
   • HTTP (type: Service)
   • Admin page (type: Page)
   • Service page (type: Page)
   • Customer page (type: Page)

   * Creating a "No access" access category, not assigning it to any role, and making this your default, means that no one will have access to a device's services and functions when you are setting up a new device. This is to prevent you from accidentally giving users more access than needed when you are still setting up a new device. Not assigning it to even the Platform administrator role makes it easier for you to detect when a device configuration has not been completed yet, because even you will not be able to see or use that service or function in the Portal.

The access categories have been created, but are not used yet. Later they will be assigned in roles to determine which users can use which service or function. First, they'll need to be assigned to a device's services and functions.

3. Go to Fleet Manager > Devices and click on one of your device names.
4. In the left menu, go to Services.
5. Open each service's settings and change the access category to the example below, or select your own.
   Example use case - Assign service access categories

   • VPN service: assign the VPN access category.
   • VNC service: assign VNC
   • HTTP service: assign HTTP
6. In the left menu, go to View.
7. Under Pages, edit existing page links or add new pages to the device following the example below, or assign your own.
   Example use case - Assign page access categories

   • Assign Admin page that you do not want the service engineers or customers to see.
   • Assign Service page to any pages that service engineers need access to.
   • Assign Customer page to any pages designed for customers.
   You can create and edit device pages to suit your or your user's needs. For help and instructions, see Create, edit, and use Device pages and Dynamic pages.
8. Repeat these steps for each of your devices.

Roles

A role is a collection of permissions and effectively determines what a user can do. The same role can be assigned to different users that are unrelated to each other, but do fulfill the same role. For example that of an engineer. Their permissions will be limited to the group of devices that they have access to, or to the individual device in case of device-specific access. A company-wide role is also an option, which grants access to all devices within the IXON Cloud company.

Think about the different roles that users within your IXON Cloud company would have, on a functional level. That determines the roles you need. Make sure that each individual role contains all the permissions that the user needs, because you can't give a user multiple roles to the same group or device. You cán give them different roles at different groups or devices.

1. Go to Admin > Roles.
2. Under Roles, add roles following the example below, or create your own.
   Example use case - Roles

   • Platform admin
     • Company-wide
     • All permissions
     • All access categories,
       except "No access"
   • Service engineer
     • Group/Device-specific
     • Manage devices
     • VPN
     • VNC
     • HTTP
     • Service page
   • Customer
     • Group/Device-specific
     • VNC
     • HTTP
     • Customer page

The roles have been created, but are not all used yet. A role is assigned to a user when you invite them into your IXON Cloud company and can also be changed after they've accepted the invitation.

1. Go to Portal > Users.
2. Either invite a new user or edit the role(s) of an existing user following the example below, or select your own.
   Example use case - Assign roles

   • When inviting service engineers, grant them the Service engineer role to their respective Partner / Integrator group.
   • For colleagues, you can choose to create a company-wide Service engineer role.
   • When inviting customers, grant them the Customer role to their respective Customer group.

Additional examples

These practical examples can help you set up your user management, act as a basis or inspiration, or simply help you to better understand user management so you can adjust it to your specific use case.

Basic: Machine manufacturer, service engineer access, no customer access

Use case / Configuration / Visualized result

Use case

A machine manufacturer that is starting with providing remote service for their machines. Either providing remote service themselves or by working together with an external party, a partner or an integrator. Customers are not granted access, but the access categories are deliberately chosen to allow for easy expansion in the future.

Configuration

Groups	Access categories	Roles
Partner / Integrator Propack Engineering Freelance Software Engineer ...	No access (default)* VPN (type: Service) VNC (type: Service) HTTP (type: Service) Admin page (type: Page) Service page (type: Page)	Platform admin Company-wide All permissions All access categories, except "No access" Service engineer - Colleague Company-wide VPN VNC HTTP Service page Service engineer - Partner Group/Device-specific VPN VNC HTTP Service page

* Creating a "No access" access category, not assigning it to any role, and making this your default, means that no one will have access to a device's services and functions when you are setting up a new device. This is to prevent you from accidentally giving users more access than needed when you are still setting up a new device. Not assigning it to even the Platform administrator role makes it easier for you to detect when a device configuration has not been completed yet, because even you will not be able to see or use that service or function in the Portal.

If you work(ed) together with a partner on a machine, assign that device to the correct Partner / Integrator group. Otherwise, do not assign a group to that device.

In the configuration of all devices, assign the VPN service to the VPN access category. Do the same for any VNC service (VNC access category) and any HTTP service (HTTP access category). Assign the Admin page access category to any pages that you do not want the service engineers to see and assign Service page to any pages that service engineers do need access to.

When inviting service engineers, grant them the Service engineer - Partner role to their respective Partner / Integrator group. For colleagues, grant them the Service engineer - Colleague role.

Visualized result

Assuming an example situation where you have 5 machines assigned to the following groups:

Machine A	Machine B	Machine C	Machine D	Machine E
Partner: Propack Engineering	Partner: Propack Engineering	Partner: Freelancer X	Partner: Freelancer X	Partner: Propack Engineering

An overview of each user's access then looks follows:

Intermediate: Machine manufacturer, service engineer expanded access, limited customer access

Use case / Configuration / Visualized result

Use case

A machine manufacturer that provides remote service themselves or by working together with an external party, a partner or an integrator. Service engineers can also manage devices to check or correct settings. Customers are granted limited access to remotely see what the machine is doing and resolve simple issues themselves.

Configuration

Groups	Access categories	Roles
Partner / Integrator Propack Engineering Freelance Software Engineer ... Customer Customer X Customer Y ...	No access (default)* VPN (type: Service) VNC (type: Service) HTTP (type: Service) Admin page (type: Page) Service page (type: Page) Customer page (type: Page)	Platform admin Company-wide All permissions All access categories, except "No access" Service engineer - Colleague Company-wide VPN VNC HTTP Service page Service engineer - Partner Group/Device-specific Manage devices VPN VNC HTTP Service page Customer Group/Device-specific VNC HTTP Customer page

* Creating a "No access" access category, not assigning it to any role, and making this your default, means that no one will have access to a device's services and functions when you are setting up a new device. This is to prevent you from accidentally giving users more access than needed when you are still setting up a new device. Not assigning it to even the Platform administrator role makes it easier for you to detect when a device configuration has not been completed yet, because even you will not be able to see or use that service or function in the Portal.

If you work(ed) together with a partner on a machine, assign that device to the correct Partner / Integrator group. Also assign it to the correct Customer group.

In the configuration of all devices, assign the VPN service to the VPN access category. Do the same for any VNC service (VNC access category) and any HTTP service (HTTP access category). Assign the Admin page access category to any pages that you do not want the service engineers or customers to see. Assign Service page to any pages that service engineers need access to and assign Customer page to any pages designed for customers.

When inviting service engineers, grant them the Service engineer - Parner role to their respective Partner / Integrator group. For colleagues, grant them the Service engineer - Colleague role. When inviting customers, grant them the Customer role to their respective Customer group.

Visualized result

Assuming an example situation where you have 5 machines assigned to the following groups:

Machine A	Machine B	Machine C	Machine D	Machine E
Partner: Propack Engineering Partner: Freelancer X Customer: X	Customer: X	Partner: Propack Engineering Partner: Freelancer X Customer: Y	Partner: Propack Engineering Partner: Freelancer X Customer: Y	Partner: Propack Engineering Customer: Y

An overview of each user's access then looks follows:

Advanced: Machine manufacturer, multiple service parties per machine with their access being limited to their own hardware in the machine, limited customer access with the option to invite colleagues to their own group

Use case / Configuration / Visualized result

Use case

A machine manufacturer that provides remote service themselves and by working together with multiple external parties per machine, a partner or an integrator. Each external party can remotely only access their own hardware, not that of other partners or integrators. Customers are granted limited access to remotely see what the machine is doing and resolve simple issues themselves. Select customers are also granted the permission to invite or remove their colleagues themselves without the need to constantly ask the machine manufacturer.

Configuration

Groups	Access categories	Roles
Partner / Integrator Propack Engineering Freelancer X ... Customer Customer X Customer Y ...	No access (default)* VPN full access (type: Service) VPN limited access - Propack Engineering (type: Service) VPN limited access - Freelancer X (type: Service) VNC (type: Service) HTTP (type: Service) Admin page (type: Page) Service page (type: Page) Customer page (type: Page)	Platform admin Company-wide All permissions All access categories, except "No access" Service engineer - Colleague Company-wide VPN VNC HTTP Service page Service engineer - Propack Engineering Group/Device-specific VPN limited access - Propack Engineering Service page Service engineer - Freelancer X Group/Device-specific VPN limited access - Freelancer X Service page Customer admin Group/Device-specific Manage users VNC HTTP Customer page Customer Group/Device-specific VNC HTTP Customer page

* Creating a "No access" access category, not assigning it to any role, and making this your default, means that no one will have access to a device's services and functions when you are setting up a new device. This is to prevent you from accidentally giving users more access than needed when you are still setting up a new device. Not assigning it to even the Platform administrator role makes it easier for you to detect when a device configuration has not been completed yet, because even you will not be able to see or use that service or function in the Portal.

If you work(ed) together with a partner on a machine, assign that device to the correct Partner / Integrator groups. Also assign it to the correct Customer group.

In the configuration of all devices, assign the VPN service to the VPN full access access category. Add VPN limited access rules for every individual Partner / Integrator that worked on the machine and assign it the VPN limited access access category corresponding to that partner / integrator (e.g. VPN limited access - Propack Engineering). Assign any VNC service the VNC access category and any HTTP service the HTTP access category. Assign the Admin page access category to any pages that you do not want the service engineers or customers to see. Assign Service page to any pages that service engineers need access to and assign Customer page to any pages designed for customers.

When inviting service engineers, grant them the correct Service engineer role to their respective Partner / Integrator group (e.g. Service engineer - Propack Engineering role to the group Propack Engineering). For colleagues, grant them the Service engineer - Colleague role. When inviting customers, grant them the Customer role to their respective Customer group. When inviting a manager from your customer, you can grant them the Customer admin role to their respective Customer group. They can then invite and remove their colleagues without needing to ask you every time.

Visualized result

Assuming an example situation where you have 5 machines assigned to the following groups:

Machine A	Machine B	Machine C	Machine D	Machine E
Partner: Propack Engineering Partner: Freelancer X Customer: X	Customer: X	Partner: Propack Engineering Partner: Freelancer X Customer: Y	Partner: Propack Engineering Partner: Freelancer X Customer: Y	Partner: Propack Engineering Customer: Y

An overview of each user's access then looks follows: