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.
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
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.
On the Remove Joins screen the Created and Modified dates are both set to "00001-01-01 00:00:00Z" for Adapter entities:
This is not impacting me in any way and I'm just mentioning it for completeness.
Using Remove Joins (to view existing joins) generates DataTables Error (SocketException: the target machine active refused it)
The following UI error appears whenever I attempt to view joins via the 'Remove Joins' menu option on a Link in the Netwealth UNIFYConnect DEV instance:
I am using Chrome on the jumpbox VM, logged in with my UNIFY credentials. The error is not written to the UNIFYBroker log.
Improved UNIFYBroker/Plus log/UI messages (de/provisioning counts, incompletes, log message grouping)
UNIFYBroker/Plus would be easier to operate if the following logging and UI messages were added or made more clear:
* A log summary of the count of entities provisioned and deprovisioned by a locker synchronisation (this may already be there, but the terminology is "added" rather than "provisioned" - it would be nice if this was consistent with the UI and clearly delineated as being different to entities "added" to the adapter via reflection)
* An log explanation of the reason(s) why an entity's provision was Incomplete - i.e. which required fields are missing, or whatever else it was that caused it to be Incomplete.
* A way to identify all of the logging messages that are part of the same synchronization operation. In a busy log file it's hard to see the wood for the trees...
* Not to report un-joined and un-provisioned entities for a linker as Incomplete during Baseline Synchronization. The configuration clearly doesn't want these entities in the locker - but the yellow (i) box that appears seems to suggests that something may have gone wrong with them.
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.
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.
Customer support service by UserEcho