Our users were running into an issue where the default "future deactivation" workflow was not running at the set time. However, i tested it and it seemed to be working fine. The only difference is that some of the pending workflows that the users had created had a different payload that was a url to wcmcommand -
/bin/wcmcommand?cmd=open&path=%252Fcontent%252Finfocenter%252F ... (rest of the path) ... &_charset_=utf-8.html
while all of my workflow instances had the expected
/content/infocenter/...
I saw this post that described why the url does not work correctly, but i'm not sure why that payload is being set with /bin/wcmcommand in the first place? With that payload it doesn't seem to run the future deactivation workflow when the time is up.
Thanks
Solved! Go to Solution.
Views
Replies
Total Likes
Found this post that explains the /bin/wcmcommand url is a known bug. So i'm assuming the future deactivation workflow just doesn't process the payload path correctly and never runs.
Views
Replies
Total Likes
Found this post that explains the /bin/wcmcommand url is a known bug. So i'm assuming the future deactivation workflow just doesn't process the payload path correctly and never runs.
Views
Replies
Total Likes