Appian Community and Appian Academy are being upgraded. From July 24–August 3, the Appian Community will be in read-only mode. During this time, the site will be read-only and user registration will be disabled. We apologize for any inconvenience this may cause, but a more secure, stable, and performant Community experience is coming soon!
The new Appian Community launches August 3, followed by Appian Academy on August 7. During the migration, Appian Community Edition, Appian Academy, Documentation, Certifications, Instructor-led Customer Training, Partner Sales Training & Accreditation, and Forum (for Appian Partners and Customers only) will remain available.
1. I have a record type of vanpool that has a related action to terminate a vanpool
2. When I execute the action from tempo, it says "action completed". Then the task shows up.
3. We need to change the behavior to open the interface/task upon executing the action
a. Terminate Vanpool process kicks off and contains a sub process , which is the main process for termination
4. Once in the main process, we have used activity chaining (we are not close to the threshold of 50)
The problem:
One of the sub processes before the task did not have activity chaining so I went ahead and added the activity chaining into this sub process and the activity chaining is still not working when this sub completes and goes back into the main process.
Troubleshooting:
After the first test, it seemed the activity chaining was not working, so I did some research, compared other sub processes within the main process and changed this sub process to run "Synchronously", then saved and published. This still did not work... in that when I invoked the action, I got the same "action completed". What else do I need to check or configure?
Thank you
Discussion posts and replies are publicly visible
Can you confirm that your related action process has activity chaining enabled on every flow line between the start node and the eventual User Input Task node?
If any subprocesses are originally set to "Asynchronous", you should leave them that way - chaining will essentially "skip over" asynchronous subprocess nodes and ignore any broken chaining found within them. Synchronous subprocesses, on the other hand, will allow chaining to proceed in the parent if and only if the flow within is fully chained.
It might be helpful if you could provide a screenshot of the process flow(s) leading up to your task. Your description pretty much confirms to me that chaining is not happening correctly between the start node and the task, one way or the other - the signs you described at first exactly match what I'd expect in this case.
This is probably to small, sorry
No worries, I was able to download the image and zoom in - the "call trip recording sync" subprocess is asynchronous so chaining inside it is irrelevant. You need to make sure chaining is enabled all throughout the two synchronous subprocesses (highlighted), as well as making sure the steps they contain don't push you over the 50-node chaining limit.
Also: can the task be moved earlier in this process flow by any means? Or does it completely rely on the processing done in all of these nodes? Usually the best answer in cases like this is to reevaluate the process flow and move certain operations to run in parallel with the task, instead of before it.
I set the call trip rec sync subprocess to synchronous before my post and had no luck.
I checked the two subs you have highlighted
1st sub is Synchronous and has chaining from the start node, to the write node, to the end node
2ns sub is Synchronous and has activity chaining on all nodes EXCEPT from the last node to the end node
We can't move the task unfortunately ..
beHumble said:all nodes EXCEPT from the last node to the end node
Well, this would break chaining in the parent process, so can you change it?
beHumble said:I set the call trip rec sync subprocess to synchronous
I'm not sure why you'd do that - this would either have no effect or have the opposite effect for what you're trying to do. Again, asynchronous subprocesses are essentially ignored by activity chaining (the subprocess launches in a separate thread essentially and can do whatever it wants). So you definitely want to leave it asynchronous.
Boom, adding that last activity chain in the 2nd sub process worked! Thank you Mike!
great, thanks for confirming.