# Enabling Zendesk and Jira Nothing leaves this app until **three separate gates** are open. Until then the UI builds the full payload, shows it to you, and the Send button stays disabled with the reason written on it. ``` 1. the integration is configured CX_ZENDESK_* / CX_JIRA_* 2. its feature flag is on CX_FEATURE_ZENDESK / CX_FEATURE_JIRA 3. sending is enabled globally CX_FEATURE_SEND_ENABLED ``` Gate 3 is the important one. A demo or staging instance simply leaves it off, and then no combination of clicks can email a customer. Check where you stand at any time on **Settings → Integrations**, or: ```bash curl -s localhost:8080/api/health | python3 -m json.tool ``` --- ## Zendesk ### 1. Create an API token Zendesk **Admin Center → Apps and integrations → APIs → Zendesk API**, turn on *Token access*, then **Add API token**. Copy it — Zendesk shows it once. ### 2. Decide which agent owns the tickets Use a dedicated agent (e.g. `cx-triage@…`) rather than a person's account, so the audit trail stays clear when someone leaves. ### 3. Set the variables ```bash CX_FEATURE_ZENDESK=true CX_ZENDESK_SUBDOMAIN=nexgencloud # from https://.zendesk.com CX_ZENDESK_EMAIL=cx-triage@nexgencloud.com CX_ZENDESK_TOKEN= CX_ZENDESK_PUBLIC_REPLY=true # false posts an internal note instead CX_FEATURE_SEND_ENABLED=true # the master switch ``` Restart. The Send button becomes live. ### What happens on send 1. Searches for `external_id:cx-triage-`. 2. If a ticket exists → adds a comment. If not → creates one, with the requester set from the Infrahub owner, priority from the screening verdict, and tags `cx-triage`, `alert-`. 3. Records a `zendesk_sent` event on the case and moves it to **Customer contacted**. So re-diagnosing the same alert updates one ticket instead of opening five. --- ## Jira ### 1. Create an API token → *Create API token*. ### 2. Confirm the project and issue type The defaults are `INFRA` / `Task`. If your Infrastructure project uses something else, set it — a wrong `issuetype` is the usual cause of a 400 from Jira. ### 3. Set the variables ```bash CX_FEATURE_JIRA=true CX_JIRA_BASE=https://nexgencloud.atlassian.net CX_JIRA_EMAIL=cx-triage@nexgencloud.com CX_JIRA_TOKEN= CX_JIRA_PROJECT=INFRA CX_JIRA_ISSUE_TYPE=Task CX_FEATURE_SEND_ENABLED=true ``` Issues are labelled `cx-triage-` and searched for before creating, so the same alert never opens two tickets. --- ## Where the credentials go **Never commit them.** | Where | How | |---|---| | Local | `.env` (git-ignored) — copy from `.env.example` | | Kubernetes | The `cx-triage` Secret, written by the pipeline from Gitea secrets | | Gitea | Repository → Settings → Actions → Secrets | The deploy job creates the Secret imperatively from the secret store, so no credential is ever in a manifest in git. --- ## Safety rails that stay on - Every send needs a click **and** a confirm naming the recipient. - No auto-send: a verdict never triggers an email by itself. - `CX_SEND_DAILY_CAP` (default 25) refuses further sends in a rolling 24 hours, so a loop cannot mail every customer. - The body is editable before sending. - Every attempt is written to the case history — including failures. - Deleting, shelving and InfraInsight edits stay copy-a-command. The read-only guarantee is what makes this safe against production. ## First run Point at a **Zendesk sandbox**, or send the first ticket to your own address by editing the To field. Once one round trip looks right, switch it on for real. ## When it fails | Symptom | Cause | |---|---| | Button disabled, "sending is switched off" | `CX_FEATURE_SEND_ENABLED` is false | | Button disabled, "not configured" | A `CX_ZENDESK_*` / `CX_JIRA_*` value is missing | | `401` from Zendesk | The email must be the **agent** address, and token access must be enabled | | `400` from Jira | Usually `issuetype` or `project` does not exist | | "Daily send cap reached" | Raise `CX_SEND_DAILY_CAP` if deliberate | | "Open the case first" | The alert has no case yet — open it in the queue once |