Introduction - Collaboration groups for AIO FLP

Updated by Daniel Sjögren

What are Collaboration groups?

Collaboration groups are designed to enable the set up of clients with an unlimited geographical hierarchy within the Quinyx All-In-One (AIO) platform.

This allows for Frontline Portal clients with organizational hierarchies deeper than 4 levels to begin using the AIO platform, just like is possible for standalone Frontline Portal clients today.

Differences between Frontline Portal (FLP) and Quinyx WFM

The key difference between FLP and WFM is that, while FLP looks at a user’s hierarchical location i.e. their position in the tree, WFM has users sitting in a flattened structure (all at unit level) and determines hierarchical position via permissions. And, as mentioned previously, the WFM organizational hierarchy is limited to 4 levels - this is not sufficient for some FLP clients.

With this functionality in place, Frontline Portal will be able to determine a user's hierarchical location based on the collaboration groups set up by the client.

By creating this Collaboration group you are effectively creating an overlay layer to the traditional WFM setup. This allows for an easy and alternative means by which a user can distribute content within the AIO product offering which breaks through some of limitations/rules of the WFM Organization hierachy.

That is, compared to the WFM Organization hierarchy, the Collaboration groups:

  1. Allow for the creation of one root level;
  2. Allow for the creation of infinite hierarchy levels (rather than being restricted to 4);
  3. Allow for mapping of employees to any hierarchy level (rather than just units + sections);
  4. Allow for mapping groups outside of their static organization;

As such, this allows for an alternative way to setup custom hiearchies for AIO customers in a more flexible way.

How Collaboration groups relate to the WFM Organization hierarchy

It is important to clarify that Collaboration Groups does not replace the WFM based Organization Hierarchy. The Organization Hierarchy is still the master in terms of how and where a client creates users, defines groups, roles, and establishes the permissions schema for their organization and is required for customers working within the Quinyx setup.

That said, from a Frontline Portal perspective there are multiple technical limitations of the WFM organzation hierarchy, which make it unsuitable for clients wishing to use FLP.

As an example - FLP gives users the option to distribute resources by ‘group type’ but there is no such concept in WFM etc.

And so these Collaboration Groups are - again - only to be utilized for AIO customers as way for them to create more complex hierarchal setups than we currently support.
Please note that you should use units to connect to collaboration groups. Districts and sections are not advised.

The first step in configuring a client’s setup - whether they use FLP, WFM, or something in between is still to start with configuring their organization in the Quinyx Account Settings.

Once a client’s users have been created and assigned to a unit, these users/units are then ready to be associated to Collaboration Groups.

Details on exactly how this “first step” works, and how to map employees to groups using the Organization hierarchy, can be found here.

Pre-configuration

Clients using Frontline Portal in the AIO platform need their configuration set in the following places:

WFM Organization management

Individual users must each be assigned to at least one unit in the WFM organization hierarchy. Users can be assigned to multiple units.

However, please note that FLP distribution does not support individual users assigned to multiple collaboration groups. If a user is assigned to multiple WFM units AND more than one of these units is then associated to collaboration groups:

  • The logic will first check If the user has been individually associated with any collaboration group. If the user is individually associated with a collaboration group, this will always take precedence within the collaboration group hierarchy. A user can only be individually associated with one collaboration group.
  • If there is no individual association, the user's home unit will take precedence within the collaboration group hierarchy. A unit can only be associated to one collaboration group.
  • If the user is not individually associated, and the user’s home unit is not associated with a collaboration group, the logic will look for the unit the user has that is assigned to the highest collaboration group in the hierarchy. A unit can only be associated to one collaboration group. If the user is assigned to two different units that are connected to two different groups in the collaboration group hierarchy that are on the same level, Quinyx picks the first one based on name.
  • There is proactive error handling when configuring Associated Groups to eliminate the risk of linking the same group to multiple collaboration groups, and throwing unnecessary validations. When configuring, you’ll be presented with that information as you configure so that easily distinguish between those groups that are available - and those that are not.
Collaboration groups
  • Hierarchical structure built, as done today in FLP standalone i.e parent/child org. groups organized into a hierarchical tree.
  • WFM units and or/individual users to each collaboration group.
  • A "Group type" label should be assigned to each collaboration group, as done today in the FLP standalone e.g. Group type = Store.

Collaboration groups must have at least one unit associated. The only exception to this rule is the lowest level collaboration group(s) in the hierarchy, for which units can be absent. Failure to associate a unit at any level, other than the lowest level, will break the hierarchical chain and cause FLP to error.

All-In-One (AIO) Frontline Portal clients must be set up with collaboration groups in addition to the WFM Organization hierarchy, irrespective of the depth of their hierarchical structure.

In the main screen for Collaboration Groups, you can view additional insights regarding the number of “Groups” and number of “Employees” that are linked to each specific Collaboration Group via either the “Associated Groups” or “Associated Employees” respectively. This should provide quick insights on the status of each Collaboration Group, so you can better understand where additional action is needed.
Additional information on “how to distribute content in the FLP portal” can be found here. Note that this Collaboration Groups initiative doesn’t really change anything from the user perspective; it just gives additional flexibility in how a user can create and manage their Collaboration Group hierarchies.

How Did We Do?