☝ In a normal path-dependent scenario, visibility of entities to be referenced is strictly governed by the OU structure. If a entity is moved in the tree from one Organization Unit to another, their new position determines their new visibility:

• Entities in the OU and below the new location gain visibility on the moved entity.
• OUs (lower in the tree) that were previously "seeing" the entity lose visibility, unless the new location is up in the same branch of the tree. 
• The moved entity loses visibility to (referenced) entities that belong to the pervious location, but gains visibility on entities of the new location.
• Effectively: The “reading up the path rule” for visibility is always applied.

☝In a non-path reference scenario (supported by Nimbus for any existing configurations), entities keep the reference to such moved entities and vice versa, regardless of their new tree position.

• Changes in the referenced entity take immediate effect for the entity that is using it.
• If a referenced entity with non-path reference is removed from the entity, it can't be referenced again (not visible according to the “reading up the path rule”).

💡 Learning: NPR are essentially a kind of "legacy access". So, even if an entity is now in a location where it shouldn't be visible to entities in the pervious OU, it still remains visible until the reference is removed manually. This must be a conscious decision by a user to keep an existing configuration intact until a “reading up the path" rule-conformant entity is selected. We will explore this concept in a few scenarios below.

Scenario 1: Moving a referenced (target) entity to another OU

This scenario applies when you move already referenced entities to another OU:

Let's assume the following OU structure:

In this configuration,

• OU A, OU A1 and OU A2 have access to Entity 02, Entity 03, and Entity 01.
• OU B, OU B1 and OU B2 have access to Entity 04, Entity 05 and Entity 01.
• Entity 04 in OU B is using Entity 05 (e.g. a playlist), but OU B2 is not using it.

If we now move Entity 05 to OU A, the following access rules changes apply:

• Non-path reference: Entity 04 in OU B keeps access to Entity 05 as long as it is using it or until Entity 05 is removed.
• OU B and OU B2 lose access to Entity 05.
• OU A, OU A1, and OU A2 gain access to Entity 05.

Examples

• Moving Playlists, Parameters to the new OU that are used in a Workflow in the old OU.
  • The workflow using the playlists and parameters retains access to them.
• Moving Opening Hours to the new OU that are used by Services in the old OU.
  • The service using the opening hours retains access to them.
• Moving Services to the new OU that are defined as a target in Workflows in the old OU.
  • The workflow having the service as a target retains access to it.

 

 

 

Scenario 2: Moving an (source) entity referencing other entities to another OU

This scenario applies when you move an entity that is using other entities or has them assigned.

Let's assume the same OU structure as in scenario 1. This time, we move Entity 04 (which uses Entity 05) to OU A:

In this scenario, the following access rules changes apply:

• Non-path reference: Entity 04 in OU A keeps access to Entity 05 as long as it is using it or until Entity 05 is removed.
• OU B, OU B1, and OU B2 lose access to Entity 04.
• OU A, OU A1 and OU A2 gain access to Entity 04.

Examples

• Moving a Workflow to the new OU that is using Playlists or Parameters from the old OU.
  • The workflow retains access to the used playlists or parameters.
• Moving Services to the new OU that is using Workflows or Opening Hours from the old OU.
  • The service retains access to the used workflows or opening hours.

💡Note that the list of examples is not comprehensive. There are numerous cases depending on your configuration. Also note that scenario 1 and scenario 2 might occur at the same time, e.g. when moving a workflow that is used by a service and is having a service configured as target.