Hyperverse Design

In most respects a Hyperverse silo can be treated like a regular Identity Panel silo. Hyperverse silos appear in the time traveler, have the same history options as regular silos, and are tied into identity join graphs.

Hyperverse Lifecycle

Hyperverse objects are initialized when an in-scope attribute flow rule imports values to the target Hyperverse silo/object type, and there is not already an existing object.

Rules should be structured so that there is only a single Hyperverse object type designated per identity join graph. For example, having separate group and user object types is fine, but separate employee and contact HV objects in the same join graph should be avoided.

Hyperverse objects are connected back to the silo join graph using the object ids of the connected objects. For this reason, it is not necessary to create Identity Panel join rules involving the Hyperverse silo.

Hyperverse objects are marked as deleted when the last connected object is marked as deleted. Like other time traveler objects, deletion is represented as a change with a timestamp and the data is not actually removed until the data retention period has elapsed.

HyperSync Panel does not support explicit lifecycle management of objects. They are created and flagged for deletion based on the in-scope attribute flow rules.

Another important characteristic of Hyperverse objects (that differs from Microsoft Identity Manager metaverse design), is that attributes are not automatically removed from the Hyperverse when an object is no longer connected into its join graph. In scope attribute flow rules populate attributes in the Hyperverse, and those values will remain until overwritten by another in-scope flow rule.

Object and Attribute Types

The Hyperverse allows definition of arbitrary object types and attribute schema. This is managed through the first tab of the HyperSync Panel settings interface.

Attributes are defined per object type, and attributes may be added and removed at any time. Removing an existing attribute from Hyperverse schema will not delete data for existing objects, but will invalidate any flow rules using that attribute.

One important characteristic of Hyperverse attributes is that they are always datatype agnostic (any type of data may flow into any attribute). The same attribute name may have differing data types on different identities (e.g. a startDate attribute might be a String on one account and a DateTime on another). This means it may occasionally be necessary to use explicit rule engine type coercion in attribute flow rules, rather than relying on the implicit type conversion of the rule engine.

In addition to being type agnostic, any Hyperverse attributes may be treated as single or multi-valued.

Although attributes may vary in type, a strongly recommended design principle is to practice good hygiene with type consistency, and define new attributes for type variations of data.

Hyperverse attributes may also be populated with reference attribute data. Like other attributes, there is no enforced distinction between single and mult-valued references. A reference value may be initialized with a direct flow or an advanced expression.For a direct flow, simply import any reference attribute from the source silo. The HyperSync engine will trace and resolve the reference across join graphs automatically. Advanced flows should return the values of references from source silos. Because all reference attributes resolve an entire join graph, it does not matter which silo is used.

See following examples:

Import a manager:

FirstNotNull(HR.ManagerId, AD.manager, Azure.manager)

Merge group membership (NOTE: the multi-value resolution process automatically eliminates duplicate values)

Flatten(AD.member, Azure.member)

Reflexive Flow

They HyperSync Panel attribute flow engine allows silos to be listed as both a source and a target. This can be used in many scenarios, for example when using advanced attribute precedence, and is particularly useful when Hyperverse attributes should be generated from other attributes.

For example, you can use one set of import rules to bring in authoritative sanitized names into the Hyperverse, then have a reflexive attribute flow rule that uses the Hyperverse attributes to generate unique account names and mail addresses, and write those to another Hyperverse attribute.

There are two design considerations to remember for reflexive scenarios.

1. Reflexive flow rules should usually have condition rules to ensure they don't come in scope until the pre-requisite attributes are fully populated.
   
2. The Hyperverse silo will only be updated once per identity per synchronization pass. This means that a progressively updated Hyperverse configuration will require multiple syncs to fully process all rules.