My client wants to grant his clients access to a screen to see status of running projects, and also create some tickets.
To do this, these users need access to the app, and be given access to this ‘viewing’ module. I would like to create a task that enables the user to do this. Fill in first and last name, email address and save. This task saves the user in the account_user table (every account has users of course), and syncs this with IAM. The user will receive an email with a link to set a password. And can then access the module.
In short, is this possible? And what would be the best approach of setting this up?
And of course, my client should also be able to delete / deactivate this user.
Blommetje
Best answer by Mark Jongeling
Hi Blommetje,
I do know many others have set up process/system flows to manage IAM users from their own end product. Would be great if they replied.
I imagine (if using the Universal GUI) that you have a process flow that starts with the task which asks for their name. After submitting that, you can utilize the Application connector to run a query on the IAM database. The query is executed by Indicium so no worries. That query creates the User. It can also add the user to a user group for example. For the password, you can set the initial password field in the usr table. After the queries are done, I believe everything is in place.
The user should now be able to access the application according to the User group, and must set a new password upon login. If the user already existed, then forget that part and only link the User group to the user. No password needed.
I do know many others have set up process/system flows to manage IAM users from their own end product. Would be great if they replied.
I imagine (if using the Universal GUI) that you have a process flow that starts with the task which asks for their name. After submitting that, you can utilize the Application connector to run a query on the IAM database. The query is executed by Indicium so no worries. That query creates the User. It can also add the user to a user group for example. For the password, you can set the initial password field in the usr table. After the queries are done, I believe everything is in place.
The user should now be able to access the application according to the User group, and must set a new password upon login. If the user already existed, then forget that part and only link the User group to the user. No password needed.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
