Provisioning AD users before first OnBase login

[Fabien_Doliveux]

Hello

I'm looking for the best way to solve a problem please :

I'm using DKT Enterprise. Target users around 40k.

They are not "day to day OnBase users", most of them will only use the DKT reader.

Each reading group is configured for an OnBase user group. A notification is send when a new document is in the user group.

OnBase user groups are mapped to active directory groups.

If I add  a document in a reading group, only users who already logged on time in OnBase received the notification.

We use the option "synchronize user attribute  on auto-logon" as OnBase is also used for other projects / wv apps.

What would be the best way to send the dkt notification to the unknown OnBase users please ?

My first lead is something like :

All AD group used for DKT are name DKT_XXXXX

Every night, a script parsed the AD, search for all groups DKT_*, and create / update / remove users in OnBase.

Perhaps there is a better way  : /

Any idea can helps!

[AdamShaneHyland · Accepted solution]

Hi Fabien,

There are a couple ways about this.  Within Config there is an tool for importing user and user groups.  This is a manual process, but will allow you to create an index file (text or XML) to import your users.  The other way is through the Unity API which has a User Management feature whereas you can manage (create, update, delete) user within the system.

Since you are looking for an automated solution, the best way would be to create a custom solution using the Unity API.  The customer application could query Active Directory for the full list of users within the respective AD user groups and then checks OnBase for those users, performing the required actions on the users (i.e. adding, updating, deleting).

Best wishes.

[Fabien_Doliveux]

Hi Adam,

Thanks for your reply. Unity API it would be so !

[dave_sanderson]

hi fabien,

this is a lower tech version which requires a pretty beefy workflow, has many moving parts and some unity scripting is still necessary. Should you have the C# chops to fully implement in the Unity API, Active Directory (AD) can be accessed, employment status/user groups can be determined from AD, the User Name does not change with employee name changes and you don't need a huge audit log, what's below probably should not be considered 😉 All should be run during off hours if not global

• DIP in a nightly export from the HR system of record to an employee Daily virtual eform
• add to workflow
• compare the employee Daily form by employee number or other value that will not change to the employee Master form in OnBase for all relevant fields (name, department, manager, position, location, etc)
• if all fields match, move the Employee Master from to a Complete Queue
  • delete employee Daily form 
  • nothing to change for that employee - this will be the majority
• if there are delta's among one or more fields
  • if the employee name changes, update employee name and email in OnBase user via  Unity Work Flow Scripts
  • if the employee position/department/location changes, update the employee user groups by Unity Work Flow Script (remove from old, add to new user groups)
  • update the information on the employee Master form
  • update the employee Master form
  • move employee Master form to a Complete Queue
  • delete the employee Daily form 
• if an employee Master form is not found, create an Employee Master form (with minimal fields)
  • create the Employee as an OnBase User by Unity Work Flow Script
  • Add the employee to the appropriate user group(s) by Unity Work Flow Script
  • update the employee Master form with all metadata
  • move the employee Master form to a Complete Queue
  • Delete the employee daily form
• when all employee Daily forms have been processed if there are employee Master forms in the daily Queue it's due to an import error, HR system export error or employee has been terminated
  • Lock the employee user in OnBase by Unity Script
  • if it's the x'th consecutive day there was no employee Daily form, safe to assume the employee has been terminated (assuming no system issues have been identified)
    • tag the employee Master form as terminated
    • remove the employee Master form from workflow
    • keep in OnBase for historical purposes
      • retention should be set to keep system clean x years post termination
  • if x consecutive days have not elapsed
    • update the Employee Master form flagged as pending termination
    • move the employee Master form to the Complete Queue
  • delete the employee Daily form

that should take care of most possibilities and auto provision users in OnBase who have never logged in......

d

[Fabien_Doliveux]

Hello Dave

Thanks a lot for your help and your detailed solution!

I'll let you know how we managed this, once done 😉