Skip to main content

Visibility groups

docs image

Visibility groups

Annonymizing data to accomodate privacy laws

The Visibility groups chapter can be your ultimate wingman when it comes to navigating through the maze of privacy laws and/or GDPR in the European Economic Area (EEA). While the feature is fantastic when it comes to keeping data safe and sound, let's not forget that humor alone won't save the day. So, put your detective hat on, check your local country laws, and perform some serious due diligence to ensure you're the undisputed champion of data protection.

Authorization

In order to be able to access this chapter, you need the VisibilityGroups permission.

Point of no return

If you plan on testing this, please use newly created organization units.

Once you add an organization unit to the visibility group, it cannot be reversed in terms of the data anonymity applied. The data that has been made anonymous as a result of your choice here is irreversible, and will remain anonymous even after unchecking the respective box.

Video​

Given that this can be a complex topic to navigate, here's a video covering everything you need to know about visibility groups. Feel free to pause at any point to delve more deeply into the topic in our docs below.

Data categories​

Using Visibility groups you can control the anonymity of the following data categories:

  • Orders: This refers to order details (order lines, status, type, quantity, etc...) An order can be visible across multiple visibility groups.
  • Organization units: This refers to organization unit details (store address, contact details, opening hour templates, etc...)
  • Users: Referring to customer data (customer address and contact details).

Based on the organization unit in which the user is accessed from, and your visibility group setup, you can control which of these three types of data can be anonymized and which can be visible. This is decided by selections made in the Visibility group configuration card.

VGs is separate from roles & functionalities

Where a visibility group allows you to see certain categories or not, it does not mean that the user will be able to see all the information from that category - this still depends on your functionalities.

Settings​

As an extra safety measure apart from the authorization required to use this functionality stated on the top of this page, and before we head off into the creation of a VG, there are a few settings that need to be set depending on what data category you want visibility groups to apply to.

  • Security:VisibilityGroups:Orders:Enabled - Setting it to true will enable filtering which orders are visible based on the visibility groups (default value is false)
  • Security:VisibilityGroups:OrganizationUnits:Enabled - Same but for organization units
  • Security:VisibilityGroups:Users:Enabled - Same but for users
  • Security:VisibilityGroups:Users:UseDefaultGroup
    • This setting ties into the one above it. While it's set to true by default, all users will be created in the same VG regardless of the organization unit they get tagged to. This means that to be able to spread users across VGs, it must be first set to false.

Overview​

The visibility groups' initial page gives you an overview of all existing visibility groups in place and the possibility to edit existing or create new ones.


filters

As always, the right side of the screen has an array of filter options to easily search across your current visibility groups.

Default visibility group​

Visibility groups come with a Default visibility group configured. This default group will usually include all your organization units (new created organization units need to be added manually or specified at the stage of organization unit creation by use of the Visibility group field).

Do not delete the default

Every environment comes preconfigured with a visibility group called Default. This group ensures that data across your existing organizational units structure is visible to each other by default. It's what comes after this setup and how you utilize it that will impact the anonymization of data categories.

Create new visibility groups​

By tapping + on the top right, you will be prompted to input a name, description, and whether to Allow standard account or not.

  • Allow standard accounts: Checking this box implies that Standard user account types are allowed. Such users are characterized by:

    • Having a unique login identifier (email/nickname)
    • Can log in
    • Can be found in the UserSearch

What this means in practice, is that by not allowing it, any consumer account created in stores will not be linked to any online (e-com) account the consumer creates later on.


Once you tap create, two new cards will be presented to you: Organization units and Visibility group configuration.


Organization units card​

Here you can specify which organization unit(s) will be part of this visibility group.


Visibility group configuration card​

Here you can specify the anonymity classification of the three data categories.


Select the source visibility group you wish to impact data from. In other words, this serves as your base source of data. This creates a one-way traffic. For example, if you're the headquarters and would like to source data from your franchise, you can. However, the franchise can only see its own data, and cannot access the data from headquarters unless otherwise established.

Now that you have your base data source visibility group in place, ticking a data category box would mean that the data falling under that category will be shared and visible across the organization units you've added via the organization units card (non-anonymized). On the other hand, a non-ticked data category means that the corresponding data of that category will be anonymized.

Settings

Make sure you have the respective settings enabled with true values in order for your visibility group configurations to take effect. Those settings were introduced as an extra safety measure since from here on onwards is what we called the Point of no return (see note on the top of this page).

Basic authorization​


When accessing an order, a series of authentication checks are performed. Anonymous users are granted the ability to modify unattached orders, while non-employees are restricted to editing only their own orders. Temporary access types are allowed for order visibility. Requests from non-employee users accessing anonymous orders created by an employee are blocked, unless the request header token matches.

Your login access is determined by the visibility group of the organization unit where your user was initially created. Depending on the access level granted to that visibility group in relation to others, you will also be granted access to view. Though you would still need the appropriate roles and functionalities in order to make any changes.

Visibility checks​


Once a user is authorized, advanced visibility checks are performed. These checks include visibility groups. If the Security:VisibilityGroups:Orders setting is set to true and any organization unit associated with the order is limited to a visibility group, access is denied for users not belonging to that group. Access is granted only if the user is part of the visibility group and the requested functionality and scope are empty. Otherwise, further checks are performed based on the requested functionalities.

Functionalities​


If the LimitOrderVisibilityForEmployees setting is set to true for employees, access is granted based on the requested functionality and scope within any related organization unit of the order. Non-employees or employees with the setting disabled are granted unrestricted access. Visibility checks are performed for various organization units, and specific permissions are required for certain functionalities such as canceling orders or modifying quantities.

Deleting a visibility group​

Deleting a visibility group is a straightforward process. You can achieve this by simply clicking the corresponding 'bin' icon in the main chapter overview. However, it's crucial to understand that deletion has significant implications that can be quite severe if not handled properly. This implication is the loss of anonymized data, including users, orders, and/or organization units based on what precisely was anonymized in the underlying configurations of that visibility group. Everything within the visibility group is deleted.

If this is the outcome you desire, such as when a franchise is completely detaching from your entity, you can use the 'bin' icon to delete the group and all its associated data. However, in scenarios where you want to still preserve this data, follow these steps:

  1. Manually clear all the organization units that were part of this visibility group;
  2. reassign those removed organization units to the default visibility group.

Scenario examples​

Here are some scenarios to help make it more clear:

Scenario 1: Marketplace​


If an order is made from a marketplace, most of the time there isn't a contractual agreement in place that would allow your organization to view or use the ordering customer details (GDPR privacy and security law).

This would mean a visibility group setup that would look like this:

  • Create a visibility group called: marketplace
  • Attach that created visibility group to the marketplace organization unit

By doing so you have now stated that the marketplace data will only be visible within the marketplace organization unit. This setup is sufficient if you only have your default(all OU's are in) visibility group in place.

Scenario 2: Web shop only​


Now let's assume a different scenario whereas you've agreed with the marketplace that customer data will remain anonymous, but order data can be shared amongst all of your web shops but not stores.

This would mean a visibility group setup that would look like this:

  • Create another visibility group called webshops
  • Attach all your web shops to this visibility group.

If you further want the marketplace to be able to view and make use of your customer data, then you'll need to go to the visibility group default and create a visibility group configuration from default to marketplace with the users box checked (true).

Making changes to employees spread across VGs

It's possible for employees to have accounts across multiple visibility groups which all share the same details (most notably: email address). If a user makes changes to its own account, then those changes will be reflected across all accounts. If a user makes changes to another user's account however, then those changes will be contained to that specific instance.


FAQ​

Before hitting that support button, why not take a peek at a few our tales on this topic.

FAQ
  • Q: My users or orders are being pushed from external systems. Are there anything additional considerations to ensure those adhere to visibility group configurations?
    • Yes, the call should include the corresponding organization unit of that order or user being pushed to EVA in the header. Without this, the call will not fall into the right visibility group and, therefore, won't be visible.
  • Q: I have a multi-visibility group configuration and hierarchy. Will my configurations be inherited?
    • Yes, configurations are inherited in a one-way direction-top down, not the other way around.
  • Q: If I have a standard account within a visibility group and place additional orders using the same email address in different visibility groups within the same organizational unit, would those orders be accessible?
    • Yes, if you have a standard account, and you use the same email address, no matter the visibility group that's configured, you'll be able to access your historic orders.
  • Q: How does EVA determine the corresponding visibility group of a user?
    • The visibility group a user falls into is determined by the visibility group ID of the user itself, rather than that of the user's primary organization unit or the logged-in organization unit. This is because the visibility group ID of the user may differ from those of their primary or logged-in organization unit.