Inside Activate
Connectors
Designing a Connector
6 min
a connector design defines how data will be matched, imported, and acted upon this section outlines how to plan and structure a connector before creating it in activate key design concepts a connector consists of schema — defines what data looks like and how changes are detected workflow — controls how imports and processing occur handlers — define what happens when data changes each connector should have a unique name a defined source of truth (hr, cmdb, sql, etc ) clearly identified key fields (for uniqueness) a delete strategy (how removed records are identified) choosing a key select a unique and stable identifier from the source system (for example, employeenumber, departmentcode, or ticketnumber) mark one column in the schema as the key \<column name="employeenumber" type="varchar(20)" default="''" key="1" /> delete strategy two supported patterns exist for handling deletes option 1 — result set deletes (recommended) only import current rows any previously imported rows missing from the current import are marked as deleted automatically example select from employees where isactive = 1 option 2 — flagged deletes import all rows, including deleted ones, and mark the condition in your schema \<deletecondition>$import$ status = 'deleted'\</deletecondition> planning for history activate can automatically log every detected change into a history table \<historytable enable="true">employee history\</historytable> this allows complete auditing of data changes and rollback validation example connector lifecycle import data into the import table compare import with current data detect changes (create, update, delete) process each change through the selected change handler trigger actions such as job submissions, notifications, or publishing