Pre-save Process

The pre-save process consists of the following steps pictured here:

Pre-save Process Steps

1. Actions During View.
   • During this stage, the entitities EntitySearch and EntityStateMail active.
     • EntitySearch - Catchable only after first save of a data card.
     • EntityStateMail - Can draw data via references, usable only after first save of data card.
2. Actions During Edit, Before Save
   • Here, references are copied and initial values for creator and creation timestamps are set. 
   • Note that some criteria created by other handlers cannot be caught during this stage.
     • ReferenceCopy
     • Expression (run via button)
     • CreatorStamp / CreationStamp (initialization)
3. Begin Saving
4. Before Pre-save Handlers, Setting Default Values and Running enable-if
   • Before the pre-save handlers run, the system sets default values (like a user macro) and conditions (enable-if) to show or hide attributes.
     • Expression (with execute early metadata true)
5. Insert defaults and do enable-if functions
   • Default value on new data card (~ user macro)
   • Show or hide attributes via enable-if
6. Pre-save handlers, run in template order
   • These are executed in a specific order and include checking data integrity and possibly block saving if criteria are not met. Also, executing scripts or calculations.
     • Validator, can block saving
     • Expression
     • MonitoringStamp
     • DataCardHiddenState
     • ValueChangeMonitor
     • ReferenceTargetCopy
     • CreatorStamp / CreationStamp update & save
7. Delayed Pre-save Handlers
   • Handlers that run after dependent attributes have been populated, which might cause delays.
     • Are run after any attributes that effect population of these, which can cause a seeming delay compared to expected running order.
     • SLADeadline
     • AttributeCombiner
8. ExecuteLate
   • See Handler - Expression
9. Pre-save Listeners
   •  Actions applied to the source data card based on the changes made during the pre-save phase.
     • Actions to source data card
10. Visual Workflow Automation initialization
    • Now the decision-making process on whether to attach automation based on changes detected by handlers and listeners must be done.
      • VWA sees changes of handlers and listeners.
      • Decision of attaching VWA to data card.

Post Save Process

1. Visual Workflow Automation Decides on Running
2. Backreference linkage creation
   • Here, references between datacards are established, affecting how and when they are saved based on the settings of the backreference attributes.
     • When reference created on this save on source will manifest as a backreference to target datacard at this point in save cycle (and similarly vice versa at this point when linking done from backref side).
     • When referencing created on this save, and Full save for target data card is set on the backreference attribute on the other side, the target data card is saved.
     • When referencing created on this save, and Full save for target data card is NOT set on the backreference attribute on the other side, the target data card is NOT saved (thus not available for VWA nodes without a delay timer or save event), but only a new history markup is made that shows the backreferencing being populated.
3. Post-save Handlers and Listeners
   • Operations here can include sending automated emails, deleting targets, transforming data, and making WebAPI calls.
     • Handlers:
       • EntitySearch (catchable on creation of data card)
       • AutoMailSender
       • TargetDeleter
       • AutoEntityCreation (acts only on data card creation)
     • Listeners:
       • Set values to target data card.
       • Do Transform.
       • WebAPI call.
       • Set value(s) to source if necessary to trigger ValueChangeMonitor (or such).
4. Visual Workflow Automation Processing
   •  Automations are triggered based on conditions and may re-save data cards, which involves rerunning handlers and listeners and updating history.
     • Each node makes a re-save (running handlers and listeners again) and a history markup
     • All nodes are run here, but timer can make a delay
     • Condition nodes check conditions at this point

Example: Changing Ticket Status with Automation 

If you change a ticket status value with automation, you want to consider:

• Statistics timestamps gets updated accordingly
• ValueChange history of status gets updated accordingly 
• Possibly hide / set visible of the datacard gets updated accordingly

If you would do this in a pre-save listener or an expression late in the template ordering, none of these would get updated by default.

There are two ways to achieve all these:

• Change the status in expression up front in the template ordering, and if necessary use a delay, such as save event to trigger the expression.
• Change the status in POST SAVE listener, to re-trigger the save process, which is the only way to also get the ValueChange created… timestamps and hide / set visible you could separately do in a pre save listener with other actions in it.