nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Workflow step - redirect after Approve/Reject/SendOn

Sebastian_Klein

Hi,

I have the situation that I send custom mails for different workflow steps to the assignees of the steps. There is a custom link inside which opens the step in SmartUI. The link itself looks exactly like the link I open when I click on the assigment in "My assignments" (e.g. /CS/cs.exe/app/processes/[SubworkID]/[SubworkID]/TaskID.
Everthing is working (also the approve/reject/sendon itself) but my only problem is that after the action was taken by the assignee there is no redirect to any site. The action is executed in the backend and user keeps staying on the workflow step. I need something (URL parameter maybe) to send the user to the homescreen (or anywhere) else after the action was taken.

Do you have any advise?

Thanks in advance.
[CS 16.2.5]

Find more posts tagged with

Comments

Appu Nair

@Sebastian_Klein
in the smart UI, I tried a simple WF step that was assigned to me who is the .After I started the WF and looked at my assignments I found it as http/OTCS/llisapi.dll/app/processes/74814046/74814046/1 when I clicked on it and completed it returned me to the home page which was ending in /app

Do you have the step as in "Allow the workflow agent to perform 'Send On' processing is that what you mean by backgrounded even with that
after sending on it changed to app I am on 16.2.6 .

one difference I am reading is you are constructing the URL in an email client so I simulated that as an outlook hyperlink
and I got the same as in the web experience...
I tested this with Disposition Buttons as well didn't make a difference

If I were you I would try it with a one or two-step workflow (simplest you can think of) and see if it is really broke
or is some other logic breaking it (You might even try what I tried to put the full URL in Notepad and put it in an email client and hit a hard return so that Outlook makes it a href because sometimes hrefs have a way to throw people off...)

Sebastian_Klein

@Appu_Nair
Thanks for your quick answer. I did a very easy simulation of this error with a 1-step-workflow but the result is the same.
Maybe I explained it wrong. The case is that I got an assigment from the workflow and open it via "My Assignments". Then for example just copy the URL of your WF step, open another browser session and paste the URL in.
It looks the same like when you access it from SmartUI Home screen but when you now click on "Approve" or "Reject" you will get either no forwarding or as in my easy example even an error message:

This is the same issue with or without "Allow the workflow agent to perform 'Send On' processing".
You can even let the fact out with the mail client. This was just the target where the link is sent to. Just simulate that you open the link to the WF step without any reference to another CS window etc. So as I wrote in a new browser session for example.

Maybe this was already solved in 16.2.6 but I would rather think it wasn't.

Thanks in advance.

Sebastian_Klein

Hi,
I found the "issue". In the end it is very easy. The workflow step is forwarding after a taken action just to the URL which is saved as referrer in the javascript variable document.referrer. Unfortunately this is just empty when I don't open the workflow step out of the browser but from a mail. Since it is empty it just forwards me to same page which is at this point of time invalid which leads to an error.

I hope this is fixed with a version > 16.2.5 since it is very easy to fix. Even a default forwarding when document.referrer is empty would help here.

Has anybody the chance to check whether it is fixed? Just copy the WF Step URL in a new tab. Then it already looses the referrer from the original tab.

Thanks in advance.

Appu Nair

@Sebastian_Klein you answered what I just posted I doubt if it is fixed in my version as well.
If you are in the mood for a little snooping here's what I would do. I would switch to the "classic UI" and it is most likely since you created the WF you are on its Master Manager List. So if you click the "Status" on its functions menu it should show you a view of the manager screen. If you isolate the WF that you have "Initiated" and trying to do work on does this step show up in "green" then it is indeed the step

I think I simulated what you are seeing if the WF Step is executed by just executing the URL(That is you have to be careful that the user does not have a browser session open anywhere) then what I observed in the other case was a temporary message would be floated on the screen like "WF has been submitted" with an auto-destruct after a small time window. In my case when there was nothing pre-opened the browser just reflected by the Chrome browser home page.

Here are some screencaps I prepared when testing this perhaps you can raise a ticket with OT and see if they concur
"See WF Status in Classic GUI and Troubleshoot.docx" can be accessed via the following link: https://knowledge.opentext.com/knowledge/cs.dll/properties/77373207

Appu Nair

I just thought of this maybe as a workaround you can give the user a Workspace URL or assignments URL & and web escaped in it the actual work URL ? would that work?

Appu Nair

While not ideal if you grab the URL from the classic ui you will get a LL page as in
https:///OTCS/llisapi.dll/app/processes/74829512/74829512/2?reload_classic_ui=true&origin_index=0
with that I tried to tweak this and was able to get a page

https:///OTCS/llisapi.dll/app/processes/74844449/74844449/1?reload_smart_ui=true&origin_index=0
but unfortuntaely everything works and smartui is maintained but you get "This task has moved along "

if you put reload_smart_ui=false then you get "this step is not yet available for editing"
perhaps REST has some indication on what one can use

Sebastian_Klein

@Appu_Nair
Thanks for all the hints. I've also two other ideas. The first is to build a redirect webreport which is opened via the mail instead of the WF task directly. This would lead to a document.referrer to the webreport. If it gets forwarded to the webreport the report will forward the request to the main page. Unfortunately it currently does not work as I expected.

The secound idea is to place an "empty" webreport widget which reacts on URL parameter set to main page (included in the mail). If the parameter is found the user gets a redirect. This fakes the click on My assigments more or less.

I'll try both variants tomorrow and let you know what will be my solution.

Btw. I'm already in contact with the support reg this issue.

Thanks.

Sebastian_Klein

Hi again,
I've now solved it via the webreport widget. It is placed on the landing page and reacts when a defined parameter is found. With this it now behaves as I expect it. Nevertheless a fix would be the better solution.

My webreport content is the following:

The custom link in the mails would look like this: .../app?wfRedirect=/7819992/7819992/3

Thanks for your support.

Appu Nair

Great hopefully OT will build a smarter interface...