Identity Broker Forum

Welcome to the community forum for Identity Broker.

Browse the knowledge base, ask questions directly to the product group, or leverage the community to get answers. Leave ideas for new features and vote for the features or bug fixes you want most.


Pending Export Report capability required to target directory

Bob Bradley 2 years ago in UNIFYBroker/Plus updated by Matthew Davis (Technical Product Manager) 10 months ago 1

There is already a Test Mode concept but this appears to be limited when it comes to providing a pre-execution reporting mechanism for ANY pending change to a target system.

Existing MIM Best Practice has incorporated this capability for many years, and the equivalent is now required in the Broker+ and UNIFYConnect platforms

Under review

Test harness for Adapter and Link PowerShell Transformations

Bob Bradley 2 years ago in UNIFYBroker/Plus updated by Matthew Davis (Technical Product Manager) 10 months ago 1

In order to support the unit testing requirements for transitioning PS solutions on Broker+ to the UNIFYConnect hosted platform, a test harness is required for all PowerShell transformations.


UNIFYBroker/Plus attempting to join source to incorrect target

Adrian Corston 3 days ago in UNIFYBroker/Plus updated by Matthew Davis (Technical Product Manager) 3 days ago 5

Log says:

20221129,21:30:25,UNIFYBroker,Link,Error,"Request to sync changes on link failed.  Request to sync changes on link Employee > AD User (ad53013b-b271-4ed6-a959-dc11aeaa5eca) in direction outgoing failed with message Source entity '0b5d5a72-fd60-4777-b1ef-f1d4a035c87d' cannot be joined to ambiguous join targets: [391e6395-a3c2-424c-9799-30a98508ac1f, 5a6e4486-75f8-4487-ab8f-4eeccf06a524]. Cannot proceed with join. [Count:4321]. Duration: 00:00:04.5645340

Link join criteria is:

Image 6392

Source entity is:

Image 6393

Target entities are:

Image 6394

Image 6395

Why would an attempt to join to 5a6e4486-75f8-4487-ab8f-4eeccf06a524 be happening, given it doesn't match the join criteria?


The root cause of this was staff from the customer's outsourced IT department updating employeeID values wrongly, in contravention of documented processes.

Please close this ticket and mark 'not a bug'.

Under review

Join calculation for source entity cannot be completed due to an invalid connection state. Reason: Source entity has multiple connections.

Adrian Corston 5 days ago in UNIFYBroker/Plus updated 5 days ago 3

After the customer remediated duplicate employee IDs in AD, UNIFYBroker is still unable to correctly join and process links.  The error message has changed to:

Synchronization job failed syncing 4322 changes on the 'Employee > AD User' link from the adapter to locker with the reason Join calculation for source entity 'e892faf3-5c17-4e9c-9be9-f9ee33cc68fe' cannot be completed due to an invalid connection state. Reason: Source entity has multiple connections.. Job ID: bf3c52ec-49a2-4655-8f00-360a6ffce78c Duration: 00:00:04.2503352

I'll attach the email thread with the customer that provides background to the next message.

Under review

Identifying previously denied entities in UNIFYBroker/Plus post-provisioning and synchronisation tasks

Entities that have been pushed onto $denySync in an link's pre-provisioning task may need to be excluded from certain operations in the synchronisation and post-provisioning tasks.  For example, if an AD user has not been excluded from provisioning then an attempt to assign birthright AD groups will always fail, and should not be performed.

If would be helpful if there was some mechanism (e.g. a $denySync.ContainsEntity($Entity) method which returns $True if the entity has been .Push()ed previously) to allow detection of this situation.

The current workaround is to duplicate/copy the code from the pre-provisioning task which determines when to add the entity to $denySync into the post-provisioning and/or synchronisation task.

Under review

Joins to non-existant adapter objects created when outgoing baseline syncs fail to provision in the connector

Adrian Corston 8 months ago in UNIFYBroker/Plus updated 2 months ago 6

I have a customer where connector entity create fails (due to external issue on the customer side) for a number of entities during link sync, and for each one I end up with a Join showing on the Locker but no corresponding adapter entity.

For example, for a baseline sync I see:  Update entities 1690 to connector AD User reported 1690 entities saved, 3 failed

After this I look at locker joins:  Showing 1 to 10 of 1,693 entries

But adapter joins says: Showing 1 to 10 of 1,690 entries

This causes problems on the next baseline sync, because even though the locker is already joined (to a non-existant adapter entity) another attempt to create the adapter/connect is still made but then this error appears:

Unify.Product.Plus.JoinExecutorTargetEntityAlreadyJoinedException: Source entity '2ac4395a-2cb7-4f6e-9d80-e6a6a38994b7' value matched to target entity 'f70abdcf-4097-4d41-84a6-b0703308f16f', however this target entity is already connected to another source entity. 'fb9d3fea-9b4a-4708-a0e1-e730551ef030'. Cannot proceed with join.

I thought we worked through this and already had a patch for this issue, but I cannot work out which ticket it was in.

Could you please investigate and see what the situation around this is?


Field mapping priority not respected when Baseline sync is run on a Link

Adrian Corston 10 months ago in UNIFYBroker/Plus updated by Matthew Davis (Technical Product Manager) 3 months ago 12

My customer has two adapters contributing data to the same locker field via two links.  I have set a priority sequence for the field, but when I run a Baseline sync on the link with the lower priority mapping the field in the locker is updated with the (wrong) value from that lower priority source. Running a Baseline Sync on the link with the higher priority mapping set the locker field back to the (right) value from the higher priority source.  The most recent Baseline sync to run always wins, regardless of the priority setting.

Image 6225

Image 6224


Allow manual Import and Sync operations while all scheduled operations are suspended

Adrian Corston 1 year ago in UNIFYBroker/Plus updated by Matthew Davis (Technical Product Manager) 10 months ago 0

When the scheduler is disabled it's not possible to run Import or Sync operations.  During solution development, initial data load and remediation activities it is often necessary to perform manual import and sync operations in specific orders while all scheduled other activity is suspended.  To achieve this right now all connector and link schedules must be individually disabled, which can be time consuming for non-simple solutions, and comes with an increased risk of schedules being left disabled inadvertently.

Provide some way to suspended scheduled operations, while allowing manual operations to continue to work.

I suggest adding a "Manual Operations Only" flag (or similar) to the dashboard.

Not a bug

Outgoing pre-provisioning task is called for some joined users

In my customer's TEST environment they are seeing AD sAMAccountName being updated for existing users where the join criteria are met.  The only place where the sAMAccountName is set is in the outgoing pre-provisioning task, which should not be called for existing joined entities.

I have also seen a second confirmation that the task is being called for pre-existing users: the "AD Account Creation" notifications being repeatedly sent for a large number of entities every time a Baseline Sync is performed.  The only place where that notification is sent is in that same outgoing pre-provisioning task.


Invalid link joins after adapter entity deletion leads to unjoinable locker

When an adapter entity is deleted any persistent joins remain and block subsequent joins to remediated data.

Steps to reproduce
1. Configure a Link with outbound provisioning and persistent joins configured
2. Import an adapter entity that is intended to join a locker entity, but which is missing its join criteria field value
3. The link will provision a "duplicate" record (thereby creating an internal "Join" for the newly provisioned adapter entity)
4. To clean up the duplicate, delete the SoT for the "duplicate" adapter record and update the "intended" record to have a correct join criteria field value
5. Attempt to join the locker to the newly corrected adapter entity - it fails and re-provisions the "duplicate" record again