Deep link to trigger custom QuickLink (custom Workflow)

[daniel_neubert]

Which IIQ version are you inquiring about?

Version 8.3

Share all details related to your problem, including any error messages you may have received.

Dear experts,

we are currently evaluating the options to provide a deep link to a custom QuickLink.
As per our analysis there is not OOTB functionality to achieve the goal, however there are some insightful discussions around this topic, e. g. the following threads

1. Expose a Form to an external Link - #6 by drosenbauer
2. Deeplink URL for Custom Quicklink
3. https://community.sailpoint.com/t5/IdentityIQ-Forum/Deeplink-URL-for-a-custom-Quicklink/m-p/234447/thread-id/178216
4. https://community.sailpoint.com/t5/IdentityIQ-Forum/launch-quicklink-by-URL/td-p/25780
5. https://community.sailpoint.com/t5/IdentityIQ-Forum/Direct-Link-and-QuickLinks/td-p/110412/page/2

We were already able to implement a simple PoC using the JSP-approach but we are wondering if this is the “correct” approach.
As per our understanding implementing a Plugin would be the “cleaner” approach to do this.
Any thoughts regarding the technology to be used, especially related to security concerns are highly appreciated.

Apart from that, would anybody be able to share some more details regarding the Plugin approach?
We were able to implement the “backend functionality” as mentioned here (1) but it seems we are missing some front-end functionality.
Would you be able to help with some details regarding all required components?

Thank you very much.

Best regards,
Daniel

[enistri_devo (Emanuele Nistri)]

Hi @daniel_neubert,

mostly, it depends on your needs.

On backend side in SP, I think you will not have some problems, SP allows a lot of flexibility. Frontend is not the best part of SP

In everycase, you need develop something in SP(with a plugin) or in your external-SP environment. In both case, you have advantages and disadvantages.

With an external UI you can call simply the workflow and elaborate the response. In this case you are free to choose the tecnology, can adapt to you site and if in future you want change UI, is not necessary touch the logic of the WF. But, you need to develop in 2 site with distinct tecnology.

In the other case, you can develop all in SP, you have all in 1 site(more or less) and the maintenance is easier(more or less). The disadvantages are more bound to SP standard.

This is a little resume of my view, I know is not so simple. Personally I prefer use SP standards, but the frontend is not user-friendly(like me ).

For me, you have to take into consideration where and how you want develop each part and which solution is better for you, in terms of time, resource and cost.

I hope I was of help to you