Currently we have the ability to use a provided interface to implement a custom connector that can synchronize data in a specified manner.

Understanding that we have the powershell logging and adapter transformation ability, I feel that it would be beneficial to give people the ability to write custom transformations and custom logging providers that can be loaded into IDB in the same way that custom connectors can be.

This would provide the ability for extended transformations that may be complex to be packaged and used as necessary, avoiding messy powershell scripts. It would also abstract the logging capabilities from the base IDB install, which means that any changes in provider functionality do not need a new release to be distributed (IE splunk changing its data endpoint).

Currently if the IDB scheduler is disabled, no connectors can run the full imports. When migrating between environments, sometimes you will copy the connector configurations across (which include a timed schedule for scheduled runs). However when doing data load for migration, you want to be able to run the specific connector full imports without other things running by themselves. Currently if the scheduler is disabled nothing can be run on the connector. Would be handy if connector imports could be run manually even with the scheduler disabled.

When viewing connector entities in IdB, there is a heading up the top which shows column names. Currently if the value of fields is large (such as an XML blob), you have to scroll to the bottom of the page to scroll vertically but then cannot see your column names which makes it difficult to know which column you're viewing.

Would it be possible to put the column names down the bottom of the table as well as up the top so you can see them at all times while scrolling?

Currently to pause a schedule for an connector you have to either disable the connector or delete the schedule for that connector.

Sometimes you want to stop the schedule for one specific connector, but still be able to run the connector. Would it be possible to add in a pause option for individual schedules per connector rather than the overall schedule?

Hi All

Is there a way to re-trigger an Outbound provision going from the Locker to AD.

- We have done a baseline sync

-  We have checked the criteria required for a provision to AD

Is this a bug or is there a solution already made?

Many thanks

Andrei

My customer has 9,000 users in AD corresponding to 7,000 in a locker of which approximately 4,000 are joined (the discrepancy being due to terminated HR users who don't have or need to be provisioned with AD accounts).

When I run a Baseline Sync on my AD link, to revert any unauthorised changes that have been made to users in AD (i.e., disable any accounts that have been manually enabled when they shouldn't have) it takes upwards of 30 minutes to run, during which time all other system processing is blocked (since link operations are blocking).  This doesn't meet customer expectations that unauthorised AD changes should be reverted within a 15-30 minute timeframe and that the system should always process low-latency operations (like manual suspensions using the Suspended Employees feature) with a delay not exceeding a few minutes.

Some possible ways to solve this problem would be to add a "true-up" operation, or allow parallel sync operations.

Customer PII has been redacted or anonymised in the screen snapshots of this topic.

Initial adapter entity:

I changed the user's first name from "Alarinka" to "Blarinka" and allowed normal processing to occur with the AD import schedule disabled so I could check the adapter entity after export.  Here's the failed export to the AD adapter, including a dump of the entity being updated (via a PowerShell reverse transform):

Adapter entity after the update is unchanged:

In AD, the rename was successful but the givenName and displayName update were not:

After a subsequent import on the AD connector (to update the adapter entity) and a Baseline Sync on the outbound locker the AD givenName and displayName details are updated correctly:

Adapter entity after AD connector import:

Baseline Sync log shows successful update:

Adapter entity after Baseline Sync:

I am pretty confident that the code that does the AD object export is renaming the AD user first, then attempting to update its attributes using the old DN rather than the new one.  The rename succeeds, but the attribute updates fail.

I suspect this bug has been mysteriously frustrating me for a long long time so if you could fix it then I would be incredibly grateful.

Allow consultants to add any SCIM attribute (core or extension) to the SCIM gateway configuration.

An automated periodic execution of the Test Connection functionality on an agent for UNIFYMonitor to pick up and report on would give UNIFY early warning that a low level service problem exists.

[Bob's suggestion]

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