Slack to ServiceNow Incident Bridge Prompt

You are an integration engineer who has wired engineering Slack to enterprise ServiceNow ITSM without making either side miserable. You will design a bidirectional Slack ↔ ServiceNow incident bridge.

I will provide:
- Our ServiceNow instance, the incident table/fields we use, and API access (REST/Table API, or an integration hub)
- How incidents start today (Slack channel, monitoring, or ServiceNow) and which side is system of record
- The ITSM fields that are mandatory (CI, category, assignment group, priority)
- The friction (engineers won't update ServiceNow; ITSM data goes stale; double entry)

Your job:

1. **System-of-record decision** — declare which fields ServiceNow owns (record number, state, priority, CI) and which Slack owns (live discussion, timeline). Avoid two-way conflicts by making each field authoritative on one side.

2. **Incident creation flow** — when an incident channel is created (or a SEV declared), auto-create a ServiceNow incident with mandatory fields mapped from the Slack declaration, and post the INC number + link back to the channel topic/canvas. Show the Table API call and field mapping.

3. **State sync** — map Slack incident states (investigating → identified → monitoring → resolved) to ServiceNow incident states, and keep them in sync. Define which transitions flow Slack→SNow vs. SNow→Slack and how you prevent loops.

4. **Worklog / timeline sync** — push meaningful Slack updates (state changes, key decisions) into the ServiceNow work notes so the ITSM record is auditable, without spamming every chat message. Define what qualifies as worklog-worthy.

5. **Webhook/event wiring** — handle ServiceNow business-rule webhooks (incident updated externally) back into Slack, with signature verification, retries, and idempotency so a single update isn't double-applied.

6. **Mandatory-field gaps** — when engineers haven't supplied CI/category/assignment group, prompt for them in Slack via a modal rather than failing the record or guessing.

7. **Failure isolation** — if ServiceNow is slow or down, the Slack incident response must NOT block; queue the sync and reconcile later. Show the buffering strategy.

Output as: (a) the field ownership/mapping table, (b) the create-incident flow with API calls, (c) the state-sync mapping and loop-prevention, (d) the worklog filter rules, (e) the webhook handler with verification + idempotency, (f) the degraded-mode buffering. Bias toward single-owner-per-field, no sync loops, and never letting ITSM latency slow incident response.