A Checkpoint is a Dodgeball Workflow used by customers to impact their flow of control as customers execute website operations. Checkpoints are initially invoked via the Dodgeball Server SDKs, with control passed over to the Dodgeball Client SDK whenever End User Interactions (Blocking Steps, such as MFA, Shared Secrets, or Document Upload) are encountered.
Client operations may await a response from the Dodgeball Checkpoint or may ignore the response. For example, Brainly does not await execution of the CARD_REGISTRATION checkpoint. If the client does await execution, they will ultimately receive a response that includes:
A status flag (SUCCESS, ERROR, BLOCKED)
A status code (0 or a negative number for specific errors, such as a user declining MFA)
A resolution (defaulting to ALLOW, but also supporting DENY).
Optionally a Custom String Message, which may consist of a JSON block serving to communicate calculated workflow values.
An example awaited checkpoint response is pictured below in raw form:
NB: The Checkpoint Call terminates either when Workflow Evaluation has terminated or when a Terminal Resolution — ALLOW or DENY — has been posted within the workflow. This allows us to give results quickly while still allowing long running process to happen in the workflow after we know whether we are going to ALLOW or DENY.
An ERROR will stop the process from continuing on unless continue on failure is turned on.