Right now we have an existing application (non-appian), it has two tables: an ap

guozhangy over 9 years ago

Right now we have an existing application (non-appian), it has two tables: an approved table and a pending table. When a record is in pending stage, it was stored in pending table and it will move to the approved table after the approval.

My question is what is the best pratice to handle the Pending records when we move to Appian? Should we keep the Pending records in the table or should we move the Pending records into the Appian Process instance? We can have three options:

1. Keep the pending records in pending table only, all the related actions (EDIT/DELETE/APPROVE) will be in a new Process Modal.
2. Keep the pending records in Appian process instances, all the related actions (EDIT/DELETE/APPROVE) will be in quick tasks.
3. Keep the pending records in both Pending tables and Appian process instances, all the related actions (EDIT/DELETE/APPROVE) will be in quick tasks.

From my experience, I feel more comfortable to use option 1, it's much e...

Discussion posts and replies are publicly visible

Parents

0 Andrew P Gramann
Certified Lead Developer
over 9 years ago

Approach 1 is much better aligned with best practices for the reasons you've already mentioned. It also generally uses less memory on the process execution engines.

Sometimes it's a little bit easier to control race conditions gracefully if you use quick tasks instead of process model backed related actions. For instance, if multiple people want to update the pending record at the same, it's easy to come up with a process variable based locking mechanism if you use quick tasks. The locking becomes a bit more complicated (though still possible) if you use standalone process instances for these actions.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 Andrew P Gramann
Certified Lead Developer
over 9 years ago

Approach 1 is much better aligned with best practices for the reasons you've already mentioned. It also generally uses less memory on the process execution engines.

Sometimes it's a little bit easier to control race conditions gracefully if you use quick tasks instead of process model backed related actions. For instance, if multiple people want to update the pending record at the same, it's easy to come up with a process variable based locking mechanism if you use quick tasks. The locking becomes a bit more complicated (though still possible) if you use standalone process instances for these actions.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

No Data