DNS Approval Workflows with Slack and Teams

The problem with approval friction

Change management systems fail when the approval step is harder than just doing the thing directly. If approving a DNS change means opening a bookmark, logging in, finding the request in a list, reading the details, and clicking approve — that's five steps competing with "I'll just do it in the console, it takes 10 seconds."

The result is predictable: people go around the process. Not because they're careless, but because the process introduces friction that doesn't match the urgency of the work. A CNAME change that's blocking a deployment shouldn't require five minutes of context-switching for the approver.

The fix isn't to remove approvals — it's to make approvals so easy that they take less effort than bypassing the workflow. If the approver can review the change details and tap "Approve" without leaving Slack, the path of least resistance becomes the controlled path. That's when change management actually works.

How one-click approvals work

The flow is straightforward:

1. An engineer submits a DNS change request (through the web UI, API, or CI/CD pipeline).
2. Netra dispatches a notification to all configured channels — Slack, Teams, Discord, email, or webhooks.
3. The notification includes the complete change details and two action buttons: Approve and Reject.
4. The approver reads the details in the notification, taps Approve (or Reject), and they're done.
5. Netra validates the action, applies the change to the DNS provider, and logs everything.

No login. No context-switching. No "let me find the request." The approver receives the notification wherever they already are — their phone, desktop, or Teams tab — and acts on it immediately.

The entire round-trip from submission to approved-and-applied can happen in under a minute if the approver is active. That's faster than logging into most DNS provider consoles.

What's in the notification

Notifications aren't just "someone submitted a request, go look at it." They contain everything the approver needs to make an informed decision without leaving the notification:

• Action: Create, Update, or Delete
• Record type: A, AAAA, CNAME, MX, TXT, SRV, NS, PTR
• Record name: The full hostname (e.g., api.example.com)
• Record value: The target or data (e.g., lb-prod.example.com)
• Domain: Which zone is being modified
• Submitted by: Who made the request
• Reason: Why the change is needed (free-text context from the submitter)
• Timestamp: When the request was submitted
• Approve / Reject buttons: One-click action links

The format adapts to each channel. Slack notifications use Block Kit for structured layout — sections, dividers, and button elements that render natively in the Slack client. Teams notifications use Adaptive Cards with the same structured data adapted to Microsoft's card format. Both render cleanly on mobile and desktop.

The goal is that the notification itself contains enough context for a decision. The approver shouldn't need to open another tab to understand what they're approving.

Security of one-click links

Putting approve/reject functionality into a link raises an obvious question: what stops someone from intercepting or replaying that link?

Each action link contains a signed token with multiple layers of protection:

• HMAC signature: The token is signed with a server-side secret. Tampering with any parameter (request ID, action, user) invalidates the signature. You can't forge a valid link.
• 24-hour expiry: Tokens expire after 24 hours. A link found in an old Slack thread or email archive won't work.
• Single-use enforcement: Once a token is used (approve or reject), it's marked as consumed. Clicking the same link again returns an error. You can't accidentally double-approve, and a replayed link does nothing.
• Request binding: Each token is tied to a specific request ID. You can't take an approve link from one request and use it on a different request.

If someone intercepts a link after it's been used — worthless. After 24 hours — expired. Modified in any way — invalid signature. The attack surface is narrow: someone would need to intercept the link in the first 24 hours before the legitimate approver uses it. And even then, the audit trail shows exactly which link was used and from where.

Setting it up

Connecting a notification channel takes under five minutes. Here's the process:

Configure the channel

In Netra's notification settings, add a channel by type — Slack, Teams, Discord, Email, or Generic Webhook. For Slack and Teams, you'll paste an incoming webhook URL (generated from your workspace's app configuration). For email, you'll configure SMTP settings and recipient addresses. For generic webhooks, any URL that accepts HTTP POST.

Choose your events

Not every notification needs to go to every channel. You can configure which events trigger notifications on each channel:

• New request submitted — the primary approval trigger
• Request approved/rejected — confirmation that the workflow progressed
• Change applied successfully — verification that the DNS change is live
• Apply failed — something went wrong during execution
• Drift detected — live DNS diverged from expected state

Most teams send submission notifications (with approve/reject buttons) to their primary Slack channel, and send failure/drift alerts to an on-call channel or PagerDuty via webhook.

Test the connection

Before relying on a channel, send a test notification. Netra dispatches a test message to verify the webhook URL is valid and the payload is accepted. If the test succeeds, you'll see the formatted message appear in your channel. If it fails, you'll see the error (usually an invalid URL, expired webhook, or permissions issue).

Start using it

Once the channel is configured and tested, notifications flow automatically for every matching event. Submit a real request, and watch the notification appear in your channel within seconds — complete with Approve and Reject buttons ready for action.

Beyond Slack and Teams

Slack and Teams cover most teams, but Netra's notification system supports several other channels for different use cases:

Discord

For teams that coordinate in Discord (common in smaller engineering teams, DevOps communities, and gaming infrastructure). Notifications use Discord's embed format with colored sidebars, fields, and action URLs. Approve/reject links open in a browser since Discord doesn't support interactive buttons from webhooks.

Email

For organizations where key approvers don't live in Slack or Teams — security teams, compliance officers, or executives who need to sign off on certain changes. HTML-formatted emails include the full change details and prominent Approve/Reject links that work with a single click from any email client.

Generic webhooks

For custom integrations. Netra sends a JSON POST to any URL you configure, containing the full event data in a documented schema. This lets you connect to PagerDuty (trigger incidents for failures), Opsgenie (escalation for unacknowledged requests), internal tools (custom dashboards, audit aggregators), or any system that accepts webhooks.

You can configure multiple channels simultaneously. A single request submission can trigger a Slack notification for quick approval, an email for compliance tracking, and a webhook to your audit aggregator — all from the same event.

What gets logged

One-click approvals don't bypass the audit trail — they're fully tracked within it. Every action taken via a notification link is logged with the same detail as an action taken through the web UI:

• Who: The user identity associated with the action (matched from the token)
• What: Approve or Reject, and which request ID
• When: Timestamp of the action
• How: Which channel the action came from (Slack, Teams, email, etc.)
• Token ID: Which specific signed link was used (for forensic traceability)

There's no difference in audit quality between "approved from the web UI after logging in" and "approved from Slack via one-click link." Both produce identical audit entries. Compliance teams see a complete trail regardless of which path the approver used.

This matters for SOC 2 and ISO 27001 audits where you need to demonstrate that every change was authorized by a specific individual at a specific time. The channel doesn't matter — the proof of authorization does.