Hi,

As Magnus has already written, it would be possible to provide such an interface via custom forms. To provide a custom form, however, you need an requestable application/authorization, just as Magnus wrote.

Custom workflows allow a certain flexibility here, but you also have to look at how you can call up the custom workflow cleanly. Within the workflows, you also have the option of making REST calls with various authentication options. I can't say right now whether you can "easily" address the Azure API with this.

In my experience, the IG is not able to record master data cleanly, or generally just provide a form for which a workflow is then stored. As far as I know, a form must always be linked to a permission or application.

BR

Tobias

Thank you both for your replies.

If the form needs to be linked to an application, how will IG handle the fact that I as the requester already made an request for this application? Will I be allowed to make another request for this application to be able to create another guest user?

Regards,

Andreas

Thank you both for your replies.

If the form needs to be linked to an application, how will IG handle the fact that I as the requester already made an request for this application? Will I be allowed to make another request for this application to be able to create another guest user?

Regards,

Andreas

I can only tell you about “permissions”, not about “applications”. I haven't really had much to do with the latter, as I've never had a use case where I needed “applications” as such, or where they would have brought me added value. But I think the behavior is similar here (not 100% sure)

We had already considered making such a custom form available via a “fake” permission. However, the problem is exactly what you have described, if the authorization is successfully requested once, then the authorization would also be assigned and therefore you could not order it again. We were considering whether to store an approval workflow that directly rejects the order. This would allow the authorization to be ordered again and again, but the order history would always show a rejected workflow. Unfortunately, I have no real practical experience with this use case, as we have decided not to go down this route. (Background: We usually also use IDM with our customers and have made the forms available there)

PS: If I remember correctly, our last consideration was the following:
Custom Application -> Fake Permission (Name e.g “Create User”) -> Permission triggers custom request forms -> request triggers custom workflow -> in the workflow you do all the stuff you want to do (calucations, REST-Calls, etc) -> Approval Workflow will be denied so you can request the 'permission' again. 

However, we never implemented this because we simply didn't find it customer-friendly.

BR

Tobias

I'm not sure if it associate the application to the identity through the request or when the collector links the account to the identity.

If it's through the collector then it maybe ok because You would not link the guest account to the requesters identity so the requester should be able to request more than one guest account.

I don't know if it works this way but maybe Tobias or someone else does?

Anyways it should be ez to setup and try.