Choose schedules and event-driven workflows
Choose between a time-based run, an application request and a workflow driven by configured feed conditions.
Begin with the business trigger. A report needed every Monday, a report needed after an application event, and an action needed when a feed condition is met are different automation requirements.
Choose the mechanism
| Requirement | Integration approach |
|---|---|
| Run a configured reporting job at agreed times | Configure the appropriate schedule and its job relationship. |
| Run a configured job after an application event | Request an on-demand Gizmo run. |
| Evaluate a configured database or FTP feed and perform actions | Configure a workflow, its feed, actions and relevant schedules. |
| Decide whether native reporting data is current | Read refresh and cache evidence. |
Configure schedules with their full context
Create schedule and Save schedule use the documented schedule model. Review its type-specific daily, weekly or monthly settings, options, enabled state, associated resource and Windows account requirements.
The ScheduleModel describes ExecutionTime as a UTC start time. Agree the intended business time zone and daylight-saving behaviour, then verify actual runs in the target deployment. Do not assume the server, browser and business location share a time zone.
Build workflows from a verified feed and action sequence
The workflow API has separate operations for the workflow model, FTP feed, actions, email, FTP destination and query configuration. Save workflow and Save Actions both use WorkflowModel, but serve different configuration steps.
Supported workflow concepts include database-feed conditions and FTP feeds, with actions such as email, query execution and configured Gizmo execution. Choose the exact feed settings, action types and required models from the reference and verify the combination in IFBI. Use the action identifiers and values supported by your installation.
Test the business condition, not just the save
Use representative input to check when the workflow fires, what actions run and what evidence confirms the outcome. Review repeated-input behaviour, source-load timing and failures before enabling production automation.
A KPI goal is not automatically a workflow trigger, and saving workflow configuration is not proof that an action has executed. Keep configuration, trigger evaluation, report execution and delivery as separately verifiable steps.
Continue with reliable API integration and troubleshooting.
Updated 3 days ago