Redirecting the Submit Button in a Workflow

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 () { = 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(; = URL;




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.


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.


How To-Best Practice
Comment List
  • Hi,


    great solution. I use this for redirection to a user overview, once a new user was created. As long als all mandatory fields are filled this works well. BUT if one misses to fill a mandatory field I simply give an alert and prevent the submit. So far so good. Once the field is filled, the Submit is not working anymore. It will redirect to the Overview, but before the user is not created... Catalina shows: "APWAException: The ID of the request you are submitting does not match the ID of the request you are viewing." Currently I have not found a solution to overcome this problem.

  • Thanks for the great post, but I have a problem with a normal button to display data from the directory. If I use a jquery button and install a function to search with the RoleVault, a redirect to the / IDMProv / TDB comes after successful execution! What am I doing wrong? I briefly see the result in Chrome and then an Erro 404 with the redirect. I can not find a solution for it in the net. Can you give me a hint?