Leveraging activity-chaining

Start process smart service is used as an alternative for the Async Sub process. It also provides the flexibility to not create dependency on a process dependents/precedents rather it asynchronously starts a process model, hence also taking care of the load balancing. 

If you want to open two forms, one after another, without falling out, you can use a sub-process synchronously and add activity chaining. 

Chaining is used to run the chained nodes on a single engine. In a normal language, It helps you jump between two or more forms without falling out but increases the engine load. This is the reason why we have a limit of 50 for chained nodes. 

Hi Harishit,

This is my PM with activity chaining, I configured form in the Start Process Smart service and I updating some data in start process smart service form and submitting and it will trigger one more PM. but, what ever the changes done in the start process smart service form was not updating in the child process.

I hope you understand the issue by this 

1.Parent Process Model

2.Configured form in the Start Process Smart service.

3.Child Process model

You can only use forms as a start form in a process model and in user input tasks! Any other node type will ignore your configured form.

I suggest to put a user input task just before the start process node.

Hi Stefan,

By using user input task before start process smart service it will work. but what is the purpose of forms tab in the start process smart service?

if they given option means we can use it right?

Thank you in advance!

Regards,

Kiran Sajjan

If they given option means we can use it right?

Sorry, but no! The configuration dialog in the process modeller is the same for almost all nodes and some options will not work.

As I said, forms will only work when used with a user input task.

Okay.

Is they mentioned anywhere in documentation not to use as form this node? or any best practices in the documentation how to use this nodes?

can you suggest me on this..

actually I am thinking it is bug in the product!

Thank you in advance!

Regards,

Kiran Sajjan

I do not understand your doubts. Each node is made for a specific purpose. And to assign a task to a user you use a user input task.

And I agree that the available options can be a bit misleading and should be improved in the product.

Peter Lewis What do you think about the option to assign a form to a node type which does not support it.

Interestingly it is technically still valid to use a form on any node that allows it (including nodes that aren't User Input Tasks). If you do this, it will correctly generate a task that is visible in the tasks feed, and it can be completed and save outputs just like a user Input Task.

However, there are a few reasons why almost no one does this in practice:

• Saving data is a bit strange. In most cases you want to guarantee that one activity occurs before another (e.g. saving the data on a form occurs before starting a process). However, since activity class parameters are evaluated in parallel, this isn't guaranteed to happen. It's usually much better to separate out the User Input Task ahead of the next node to guarantee the order of operations.
• Debugging is also harder if you combined everything together into a single node, as the process history can't provide granular enough detail to give context for what occurred within a node.

For those reasons, it's best practice to not use the Forms tab within any node except for User Input tasks.

Interestingly it is technically still valid to use a form on any node that allows it (including nodes that aren't User Input Tasks). If you do this, it will correctly generate a task that is visible in the tasks feed, and it can be completed and save outputs just like a user Input Task.

However, there are a few reasons why almost no one does this in practice:

• Saving data is a bit strange. In most cases you want to guarantee that one activity occurs before another (e.g. saving the data on a form occurs before starting a process). However, since activity class parameters are evaluated in parallel, this isn't guaranteed to happen. It's usually much better to separate out the User Input Task ahead of the next node to guarantee the order of operations.
• Debugging is also harder if you combined everything together into a single node, as the process history can't provide granular enough detail to give context for what occurred within a node.

For those reasons, it's best practice to not use the Forms tab within any node except for User Input tasks.

Thank you very much for this excellent description Peter Lewis. Very much appreciated :-)

Thank you very much Peter Lewisfor clarifying my doubts.

Thank you for your great help in clarifying my doubts .