Process Gating
With PixieBrix, you can add process telemetry and gates to any page. By recording telemetry to a Team Database, your operations teams can easily track business value in Excel and business intelligence tools such as PowerBI
Mod Structure
The basic mod structure:
- Collect/extract context
- Business logic to determine a business scenario
- Record telemetry to the database
- Conditionally show form (based on the business scenario)
- Update database record with a form response
Brick | Output Key | Condition | Description |
data | Extract information from the page, using component or JQuery reader | ||
@pixiebrix/document-context | context | Read URL and timestamp | |
@pixiebrix/session | session | Read session (team member email) | |
@pixiebrix/jq | scenario | Use the jq brick to encode business logic to determine the scenario and whether or not to show the form | |
@pixiebrix/data/put | ignore | Put context about the | |
@pixiebrix/form-modal | form | @scenario.ShowForm | Show the form to the team member
NOTE: if you need to perform cleanup based on the user’s response, set cancellable: false on the form and use optional fields. If the user cancels a form, the bricks after the form won’t be executed |
@pixiebrix/data/put | ignore | @scenario.ShowForm | Put same data as before showing the form, but also include the form data |
{{ "true" if @scenario.ShowForm and not @form.OverrideReason }}
(Nunjucks template syntax) | (Optional) Undo the action (e.g., clear the field) if the user did not provide the necessary information in the form |
PixieBrix Team Database Structure
For process gating, use a single Team Database that’s written to before showing the form, and then update the record with team member responses.
Pro-Tip: use the same terminology for values as the business scenarios/requirements so the business team does not have to transform field names/values when ingesting data
Column | Null/Blank | Description |
Id | FALSE | Unique identifier for the attempt, e.g.: {{@context.url}}-{{@context.timestamp}}
Be sure to include a timestamp or other instance identifier if the team member can attempt the action multiple times for the same resource |
data.Email | FALSE | Email of the team member (from Session Reader) |
data.EntityId | FALSE | Identifier for the resource, e.g., @context.url |
data.ScenarioName | FALSE | Scenario name of business scenario or failure case. For example: “Valid Refund”, “Invalid Refund”
Should correspond to business requirements |
data.ShowForm | FALSE | TRUE if the form was shown to the user, FALSE otherwise |
data.BusinessMetric | FALSE | Business metric for aggregation. E.g., refund amount, dispute amount, account credit, etc. |
data.OverrideReason | TRUE | The Override Reason the team member entered into the form
NULL/BLANK if the user was: 1) not shown the form, 2) cancelled the form, 3) or did not provide a value |
data.ManualOverride | FALSE | Set to TRUE if the team member has provided necessary information for the process gate |
data.CancelledForm | FALSE | (Optional Field) When using the cancellable forms. Set to TRUE before showing the form, and FALSE after showing the form. (If the team member cancels the forms, the bricks after the form will not be executed) |
Business Metrics
Metric | Calculation | Description |
Number of Events | COUNT(*) | Number of recorded events |
Number of Events per Scenario | GROUPBY(data.ScenarioName)
COUNT(*) | Number of recorded events by business scenario |
Actions Prevented | FILTER(data.ShowForm AND NOT(data.ManualOverride))
COUNT(*) | Number of events where the team member was shown the form but did not provide a manual override |
Manual Overrides | FILTER(data.ManualOverride)
COUNT(*) | Number of events where the team member was shown the form, and entered and override reason |
Cost Avoided | FILTER(data.ShowForm AND NOT(data.ManualOverride))
SUM(data.BusinessMetric) | NOTE: once Process Gating is deployed, team members should overtime also decrease the number of attempts |