A Locker field value change is not appeared in an Adapter when Changes Synchronization runs.  The same Locker/Adapter are able to provision objects just fine.

The UNIFYBroker/Plus config and logs are available in the Netwealth UNIFYConnect DEV instance; the Locker is "Employee", the Adapter is "SPOL Employee Suspensions", the Link is "Employees > SPOL Employee Suspensions".  To trigger the change I make a change to a field value in the Employee connector source (an SFTP CSV file), run an Import All on the "ELMO Employees" connector, a Changes Synchronization on the "ELMO Employees > Employees" Link, then finally the Changes Synchronization on the "Employees > SPOL Suspended Employees" Link (which causes the following error to be written to the log):

The follow error occurs:

To replicate, create a Link for an Adapter, delete the Adapter and then attempt to edit the Link.

After deleting a Link, Adapter and Connector the following error is persistently appearing in the Netwealth UNIFYConnect DEV instance:

Could you please investigate and advise how to get rid of it?

When deploying UNIFYBroker/Plus the LDAP name restriction for adapter field names is unnecessary - could you please offer a way to turn it off.

Hi Matt,

In a past discussion with you I mentioned the importance of being able to know both the old and new value of an attribute when deciding to trigger an email notification, and this is an example of that.

Here’s an email requirement detail clarification just in from a UNIFYConnect customer:

“Speaking of emails, a manual process we may have missed. When a staff member is assigned an email address, we manually send them a welcome email from our CEO. If we provide the email content, etc, can you include this step in automation for new (email) users?”

Can you advise how I can detect that an email address attribute (imported from AD) has changed from blank to non-blank? Email addresses are assigned by Exchange policy so that’s the only way I can think of to detect and trigger the above action.

In a MIM context we have been refining our Safety Catch to ensure that unwanted changes (not just deletes) are not replicated to target systems if the change count exceeds a threshold (% or raw number).  The latest version is presently pending deployment for a long-term MIM site.

With the roll-out of more Broker+/UNIFYConnect implementations, an equivalent safeguard feature is now required - over and above the "connector delete threshold" native to UNIFYBroker itself.  Until such a feature is available in a forthcoming release, a work-around should be considered for each implementation.

As-built of the nature of MIM Documenter and AAD Connect Documenter has long been an expected artifact of the Microsoft Workplace Identity Practice for all MIM and AAD Connect deployments.

Something at least similar to the SuccessFactors default attribute mapping can be generated for our UNIFY* customers as part of handover to BAU, providing a quick reference for both the customer and support alike.

Similar to the checklist developed on the back of the ultimately successful WA Water Lite implementation, this Aurion Pre-installation Checklist contains the necessary steps for a successful implementation UNIFYBroker+ as well as both UNIFYAssure and UNIFYConnect IdAAS flavours.

An updated checklist will now be required for each of the in-flight UNIFYConnect implementations, as well as future Broker+ installations (where the server specs are still required), and apart from the following recommendation needs to be specified by Engineering:

• Correlation IDs are available in all production and non-production Active Directory environments

With the increased focus lately on deployments of the UNIFYAssure/UNIFYConnect/UNIFYBroker+ solution set, recent experience has been that at times it would have been handy to still use UNIFYNow to enhance the operations user experience - even without MIM in the picture, the familiar Operation List concept could apply equally to a Broker+ deployment as it can for MIM sync.

While we may consider pursuing this idea, a better outcome would be to incorporate UNIFYNow features in the UNIFYBroker+ product configuration itself (i.e. not only adding the Locker menu, but also an Operations menu ... sharing the existing Agents/Groups/Logs menus I imagine, and using the Groups concept to simplify the UX.

In scenario where pre/post processing is required (e.g. mailbox provisioning, notifications, workflow-like activities, etc.) such a configuration would undoubtedly be more maintainable and operationally easier to handle than it is without the UNIFYNow model we enjoy today for MIM solutions with similar out-of-band integration.

I am building a customer solution that requires an email to be sent to a user's manager when that user's attribute changes to a particular value (i.e. employeeState from "pending" to "active").

How can I implement this in UNIFYBroker/Plus?  This is functionality that is likely to be generally necessary, as customers often have a requirement to initiate a once-off event/action in response to a user's changed circumstances.