Hierarchy

Organization
An organization is the highest entity on the totem pole. It usually contains one or multiple subscriptions. An organization never contains a Point of Sale.
Example: Marvel Group Inc. is the holding company who owns several companies / brands.

Subscription
An organization can have one or multiple subscriptions, which are usually brands, divisions or companies owned by the organization. A subscription usually always contains at least one Point of Sale.
Example: Oscorp, Stark Industries and Daily Bugle are all individual companies with their own employees which are all owned by Marvel Group Inc.

Point of Service
A Point of Service is usually a brick-and-mortar store, but it can also be a different segment of a business like a pickup point or a non-physical location for online businesses.
Example: Montreal is only one of many Points of Service Oscorp has around the country.

Users
Users can be part of the organization or subscription level. A user on the organization level can have access to any or all of the owned subscriptions. A user of a subscription can only have access to that organization’s resources.
Example: Marvel Group Inc.’s employees could have access to any or all subscriptions to monitor them while an employee of Oscorp would only have access to Oscorp’s resources and none of Stark Industries (as that would be a security risk for Iron Man).
Marvel Users:

Oscorp Users:

Services
A service is a product under Hexia. Voice of customer, Mystery Shopper and Hexia Local are good examples of a service. There are several services available, and you can set the permission for each of them individually. You can also have multiple service items under the same subscription depending on the service. You can also have more than one service item of a type under the same subscription.
Example: Stark Industries need two Voice of Customer Services, one survey for post purchase and one for post-delivery of armored goods, as well as an hexia local service to monitor what users say online. So the admin created 2 VoC service item and 1 hexia Local service item.

Two ways to grant permissions
There are two ways to give a user permissions:
Individual permissions: Allow you to give fine-grain permissions to any individual you wish.

Group permissions: In larger organizations, it could be very time-consuming to create individual permissions for every employee so it might be a better idea to create groups, each with their own permissions, and then assign users to one or multiple groups.

Example: All project managers have the same permissions, which are different compared to the employees belonging to the marketing department.

Permission Role Levels
Different roles can access different functions depending on services. A reader might have read-only access to data, while a contributor might be able to edit the data and an administrator might be able to do all this and set alerts as well. See the table below for permission level details per service.
Administrator Portal
Permissions / Roles | Owner | Administrator | Contributor | Reader |
Access the Administration portal | x | x | ||
Create / Edit / Delete a Subscription | x | x | ||
Create / Edit / Delete a Service | x | x | ||
Create / Edit / Delete a User & Permissions | x | x | ||
Create / Edit / Delete a User Group & Permissions | x | x | ||
View a PoS | x | x | x | x |
Create / Edit | x | x | Edit | |
Create / Edit / Delete a PoS Group | x | x |
Voice of Customer
(Filtered by PoS / PoS Group Permissions)
Permissions / Roles | Owner | Administrator | Contributor | Reader |
Access the Dashboard | x | x | x | x |
Access the Alerts | x | x | x | x |
Edit / Forward / Change Status of Alerts | x | x | x | |
Access to the Result Section | x | x | x | x |
Access to the Competitor Results Section | x | x | x | x |
Access to the Trends Section | x | x | x | x |
Access to the Report Section | x | x | x | x |
Access confidential information | Requires the CI permission | Requires the CI permission | Requires the CI permission | Requires the CI permission |
Mystery Shopper
Permissions / Roles | Owner | Administrator | Contributor | Reader |
Access the Dashboard | x | x | x | x |
Access to the Result Section | x | x | x | x |
Access to the Report Section | x | x | x | x |
Access confidential information | Requires the CI permission | Requires the CI permission | Requires the CI permission | Requires the CI permission |
Owner / admin note:
The Users added at a subscription level will show up at the organizational level. A user created at the organizational level will be able to assign permissions at the subscription level. (Ex. Accessing Marvel at the organizational level vs Oscorp and Stark Industries at the subscription level).
Point of Service and Services Permissions
To have a working account, a user needs to have two permission levels: one to the service you want the user to access and another one to a Point of Service or a group of Point of Service. Together, this determines what a user has access to.
Example: A user could have access to the Voice of Customer service but still see no data as there is no Point of Sale assigned. Assigning this user the Montreal Point of Sale would give access to the data for the Montreal Voice of Customer service.

Point of Service Group
As with users, you can create PoS groups. How you group these are up to you. They can be grouped together by region or even under the name of a regional manager. A PoS can be assigned to multiple groups and are also a handy way to filter data in the dashboard as per an organization’s requirement.
Example: Creating the Mary Jane Department group and assigning both the Montreal and Toronto PoS to this group will allow Mary Jane Watson to see both PoS data. She wouldn’t have access to Gwen Stacy Department’s group, however, unless an administrator gives her group rights to that group too (but it won’t happen because they don’t see eye to eye).

Multiple group permissions note: if you give multiple group permissions to a user, some might overlap, and it might get harder to determine what a user can and cannot have access to. For example, if the Montreal PoS for Mystery Shopper is in both the Mary Jane and Gwen group removing it from Mary Jane’s group won’t prevent a user with the Gwen group permission to see it. An administrator can use the impersonation feature to validate what a user can and cannot see.
User Impersonation Feature
Admins can gain insight into individual user permissions through the “User Impersonation” feature. By clicking on the Mask icon located in the user permissions, admins can view the platform from the perspective of a selected user, allowing them to understand exactly what the user has access to.
Example:
If Normand Osborn is assigned permissions exclusively for Oscorp, an admin can use the impersonation feature to view Hexia as him, validating that Mr. Osborn should only have access to Oscorp-related functionalities.
How to Use The Impersonation Feature:
- Click on the mask next to a username in the User table
- Once in the user impersonation view, an orange bar (referenced in the image below) will appear to indicate that the admin is viewing the platform as another user, preventing any confusion with their own account.
- To exit this view and return to the admin account, simply select the arrow icon located at the top right of the orange bar.
This feature is crucial for ensuring each user’s experience is optimal and their access is appropriately allocated, maintaining a seamless and secure user interface.


Addition and Inheritance concept
Hexia uses an additive permission system. This means you can easily add permissions and stack them together, but they can never be subtracted.
Example: If everyone in the Pepper Pots Department group has a contributor permission to a resource, all other linked permission in the hierarchy must be at the contributor level or higher. You can add an administrator permission to a resource, but you cannot lower someone to reader level. If you need more fine-grained permissions, use individual permissions and do not use groups for this use case.

Additional permissions
Some additional permissions are available to stack on top of those discussed above. These are usually service specific.
Example: You might require one of your Customer Support Specialist to manage contests and have access to user’s confidential information. In that case, add that user to the Customer Support Specialist group and simply add the individual permission named confidential information permission to that user. Everyone else in the group won’t have access to confidential information.
Ex. Pepper Pots assigned to Customer Support Group:

Ex Pepper Pots individually assigned Confidential Info:
