From time to time, I have wanted to use workflows where the submit button does not go back to the User Application. For example, if you are using the workflow as the starting point of user self-provisioning, you might want to deep-link it off a portal, and then send the user to a custom landing page which provided friendly instructions on how to proceed.

Another use case which one of my colleagues was building for one of our clients involved using the PRD deep links on tiles on the IDM Dashboard. The challenge was the submit button was taking them back to the user application.

There is a method within the form object of the form script API called “interceptAction()” which is intended to add actions associated with the form action buttons. Action buttons on a request form by default are “SubmitAction” and “CancelAction” (differently named similarly implemented buttons are part of the request form).

InterceptAction() takes three parameters:

1. The name of the action

• A keyword indicating when to intercept

• An ecmascript (javascript) function to be run

The three values for “when” are:

• before

• around

• after

The most commonly used one is “around”. This one passes in an object with a method to determine whether or not to proceed with the submit. Normally this is used for form validation of some sort. Selecting “before” will pre-empt the action of the button. Theoretically, “after” should run after the submit is completed.

I say “theoretically” because I have never seen before vs. after operate differently. Placing either one to intercept the submit button causes the action to be taken but the workflow is never started. But what I have been trying to do might be at the heart of that issue.

What I want to do is redirect the browser after the workflow is submitted to a new URL. The challenge with this is that the http POST which implements this submit is done inside some javascript which also directs you immediately to the “done” page within the User Application, so the intercepted redirect doesn’t happen. If you succeed in the redirect first, you are no longer on the page which can do the submit.

In order to solve this problem, I designed a simple solution to replace the submit action’s underlying event handler. To implement:

1) Place the following code in your form onload event handler:

landing ="/idmdash/#/landing"; form.interceptAction("SubmitAction", "around", function (invocation) { field.fireEvent("SubmitAction-invocation-proceed",landing); invocation.proceed();} ); form.interceptAction("CancelAction", "after", function () { window.top.document.location.href = landing;} );

2) In any one field (Advice: use the first or last one so you can find it easily) create an event handler named “SubmitAction-invocation-proceed”. Put this code in there:

function newSubmitAction1Click(URL) { SubmitAction1Click(this.name); window.top.document.location.href = URL; } document.getElementById("SubmitAction1").removeEventListener("click",SubmitAction1Click) document.getElementById("SubmitAction1").addEventListener("click",newSubmitAction1Click(event.getCustomData().toString()));

Now it’s important to note that if you use these links from a “featured item” inside the request tile in idmdash, it will in fact return where to you want it to. This is because of some very clever restyling and insertion of new javascript into the form which relies on dojo and ajax (I tried to re-purpose that, but it’s quite complex and appears to have many dependencies on the new platform). The reason our client wanted to do this within the idmdash is to place particular workflows on the main idmdash page.

Conclusion

Often, we see functionality that we want to “cherry pick” from systems like IDM and include within our own web portals. The inherent behavior of the solution can sometimes place unnatural obstacles to this creativity. I hope this code can also be leveraged to enable the inclusion of PRDs into nearly any place you wish within your web content and control the post submit behavior any way you wish.