Inside Activate
Connectors
Introduction
3 min
connectors bring external data into activate on a repeatable schedule, detect changes, and trigger the right workflows automatically each connector is a self contained unit with its own schema , workflow , and change handlers , so you can run many connectors in parallel without overlap what connectors do import data from source systems into a staging ( import ) table compare staged data with current ( data ) table to detect create / update / delete events process each change using configurable handlers (e g , users, roles, generic, script, tickets) act by submitting jobs, executing scripts, publishing/unpublishing, or sending notifications why use them keep activate aligned with hr, erp, cmdb, or ticketing systems drive lifecycle automation from real data changes maintain a clear audit of imports and state changes how a connector is structured schema — defines tables ( datatable , importtable , historytable ) and their columns, keys, and delete rules workflow — defines steps that load data, detect changes, and run handlers ( clearimport , import , processimport , process , plus optional steps like execute , run , notify ) change & link handlers — define how detected changes are acted upon or linked to existing activate objects (e g , ad users, roles, tickets) who this section is for implementers & administrators designing data flows and guardrails developers extending import providers or event logic operations teams monitoring connector runs and troubleshooting errors typical use cases hr feed → user provisioning create, move, and disable users automatically department hierarchy → roles keep organisational roles aligned with external structures service desk integration → ticket sync update activate tickets based on external statuses think of a connector as data shape (schema) ➜ change detection (workflow) ➜ business action (handlers)