Trigger Error Handling

Pros:

• Easy to implement and access error messages.

• Low maintenance - The code used is generic enough that we wouldn't need to go in and make individual changes for each workflow (i.e. updating UID's).

Cons:

• Probably not the best place to store errors.  Should really be used for the business issues.

• Need to implement a message that highlights to the user that there has been an error and they should look at the case notes.

• Need to grant permissions to access case notes.

• Can't prevent a user from going forward.

Pros:

• Prevents a user from going further in the Process until the error has been resolved.

Cons:

• The PHP code to do this uses specific UID's for the routing.  We would need to update these for each new workflow.

• Potentially high maintenance.

  • When updating a workflow, we would need to keep the UID's in mind for any changes made after it's finished.

  • There's currently no "dynamic" way of getting a step number and so any changes would need to keep this in mind

Pros:

•   Prevents a user from going further in the Process until the error has been resolved.

Cons:

• The PHP code to do this uses specific UID's for the routing.  We would need to update these for each new workflow.

• Potentially high maintenance.

  • When updating a workflow, we would need to keep the UID's in mind for any changes made after it's finished.

  • There's currently no "dynamic" way of getting a step number and so any changes would need to keep this in mind

Pros:

• Force the user to go back to previous steps and don’t let them route to the next task.

• Template could be re-usable across multiple workflows.

Cons:

• These screens can only be implemented as the "route" step in a task, so it cannot be implemented between two dynaforms.