Knuckles-Team Servicenow Change Tracker Workflow
CONCEPT:KG-2.12
Fetch active ServiceNow Change Requests sorted chronologically
Steps
Step 0: ServiceNow Change-Request Query [skill: servicenow-api]
Agent: intake-agent
Tools: graph_query, nc_files
Retrieve a list of active change requests using the servicenow_change_management action with action='get_change_requests'. Specify a chronological descending query via params_json (e.g. {"sysparm_query": "active=true^ORDERBYdescsys_created_on"}).
Step 1: Change-Selection Interaction [skill: user-interaction]
Agent: processor-agent
Tools: graph_analyze, document_tools
Display the chronological change log and scheduled maintenance windows to the user. Ask if they wish to inspect a specific change ticket or analyze scheduling conflicts.
Step 2: ServiceNow Change-Request Inspection [skill: servicenow-api]
Agent: validator-agent
Tools: graph_query
Retrieve comprehensive details for the selected change request ID using servicenow_change_management with action='get_change_request' and action='get_change_request_conflict' to detect environmental schedule clashes. Both actions key on params_json containing {"change_request_sys_id": "<sys_id>"} — the underlying ChangeManagementModel field is change_request_sys_id, not sys_id; passing sys_id is silently dropped and the call fails with MissingParameterError.
Step 3: Change-Detail Presentation [skill: user-interaction]
Agent: report-agent
Tools: graph_write, document_tools
Present the detailed change payload, risk factors, conflict scan report, and approval paths to the user.
Step 4: KG Persistence [depends_on: Step 3]
Agent: report-agent
Tools: graph_write
Persist workflow results as nodes and edges in the Knowledge Graph. Create appropriate typed nodes with metadata and link to existing domain entities.
Output
- Servicenow Change Tracker results persisted in KG
- Structured report (MD/PDF)
- Audit trail with timestamps and agent attributions
Human Oversight Required
✅ Critical decisions require human review and approval.
Execution
Run this workflow as a dependency-ordered DAG. Steps with no unmet depends_on run in parallel; dependents run after their prerequisites complete.
- Run first (in parallel): Step 0 — ServiceNow Change-Request Query; Step 1 — Change-Selection Interaction; Step 2 — ServiceNow Change-Request Inspection; Step 3 — Change-Detail Presentation
- After level 0: Step 4 — KG Persistence
Execution: If graph-os is reachable, offload the whole DAG via graph_orchestrate action=execute_workflow (or the kg-delegate skill) for true parallel/swarm execution. Otherwise execute the steps natively in dependency order: run steps with no unmet depends_on in parallel, then their dependents.