> ## Documentation Index
> Fetch the complete documentation index at: https://dialnexa.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Control D

> Connect DialNexa calls to Control D for vault item, access request, identity check, security review, policy exception, or suspicious-call escalation workflows.

Control D is a customizable DNS filtering and traffic redirection platform that allows users to manage internet access, enforce policies, and monitor usage across devices and networks.

<Note>
  Use Control D with DialNexa when the caller asks for access, recovery, permission changes, vault help, or anything that could expose sensitive systems.
</Note>

## Where Control D fits in a DialNexa workflow

Control D should receive DialNexa output when the conversation affects a vault item, access request, identity check, security review, policy exception, or suspicious-call escalation. The handoff should explain what the caller asked for, what DialNexa learned, which record or object is affected, and who owns the next step.

<CardGroup cols={2}>
  <Card title="Preserve the audit trail" icon="check-circle">
    Attach call ID, owner, decision, timestamp, and review outcome so security can reconstruct what happened.
  </Card>

  <Card title="Route policy exceptions" icon="check-circle">
    Send unusual access requests to the correct security or IT owner with the policy, reason, and urgency attached.
  </Card>

  <Card title="Verify the caller before access changes" icon="check-circle">
    Capture who called, what access they requested, which workspace is affected, and whether identity confidence is high enough for review.
  </Card>

  <Card title="Escalate risky requests" icon="check-circle">
    Flag callers asking for secrets, emergency access, admin changes, recovery help, or unusual account actions.
  </Card>
</CardGroup>

## What DialNexa should capture for Control D

* Caller identity, organization, role, account, phone, and verification confidence
* Requested permission, policy exception, recovery action, affected system, and severity
* Risk reason, suspicious phrases, urgency, approval requirement, and escalation owner
* Safe summary, transcript link, recording link, DialNexa call ID, and review status
* Redaction flag for secrets, tokens, passwords, keys, or recovery codes

## High-value Control D workflows

<AccordionGroup>
  <Accordion title="A caller mentions leaked credentials or phishing">
    For this workflow, DialNexa should send Control D a concise, action-ready handoff: matched caller, affected record, reason for the update, urgency, owner, next step, and links to call evidence.
  </Accordion>

  <Accordion title="A manager wants an audit trail for an access exception">
    For this workflow, DialNexa should send Control D a concise, action-ready handoff: matched caller, affected record, reason for the update, urgency, owner, next step, and links to call evidence.
  </Accordion>

  <Accordion title="A suspicious caller repeats failed verification attempts">
    For this scenario, DialNexa should treat Control D as an escalation destination. Send the impact, urgency, affected customer or object, owner, and transcript link so the right team can act before the issue gets colder.
  </Accordion>

  <Accordion title="Security needs a post-call incident note">
    For this scenario, DialNexa should treat Control D as an escalation destination. Send the impact, urgency, affected customer or object, owner, and transcript link so the right team can act before the issue gets colder.
  </Accordion>

  <Accordion title="Caller asks for emergency account recovery">
    For this workflow, DialNexa should send Control D a concise, action-ready handoff: matched caller, affected record, reason for the update, urgency, owner, next step, and links to call evidence.
  </Accordion>

  <Accordion title="Employee requests access to a restricted vault">
    DialNexa should keep this people workflow minimal and private: identity, role or case, requested next step, owner, timing, and sensitivity flag. Do not copy unnecessary personal details into Control D.
  </Accordion>

  <Accordion title="Support needs identity confirmation before sharing private details">
    For this workflow, DialNexa should send Control D a concise, action-ready handoff: matched caller, affected record, reason for the update, urgency, owner, next step, and links to call evidence.
  </Accordion>

  <Accordion title="Use create custom rules in profile folder">
    Use create custom rules in profile folder only when DialNexa has a matched caller, a clear destination object, and enough call context to justify opening a new security record. If the caller is unclear, route to review instead of creating noise.
  </Accordion>

  <Accordion title="Use update profile schedule">
    Use update profile schedule when the caller changes a field, status, owner, date, priority, note, consent choice, or next step on an existing Control D record. Include the old value, new value, and reason from the call.
  </Accordion>
</AccordionGroup>

## Workflows that pair Control D with other integrations

* [Control D](/integrations/control_d) + [Google Docs](/integrations/googledocs): Google Docs for audit notes and incident summaries.
* [Control D](/integrations/control_d) + [Google Sheets](/integrations/googlesheets): Google Sheets for access-review queues.
* [Control D](/integrations/control_d) + [HubSpot](/integrations/hubspot): HubSpot for account-owner awareness on enterprise customers.
* [Control D](/integrations/control_d) + [Gmail](/integrations/gmail): Gmail for approved follow-up after review.
* [Control D](/integrations/control_d) + [Zendesk](/integrations/zendesk): Zendesk for the support ticket that triggered the access request.
* [Control D](/integrations/control_d) + [Slack](/integrations/slack): Slack for urgent review by security or IT.

## Implementation notes

* Use the DialNexa call ID as the idempotency key before running Control D actions.
* Write a short operational summary into Control D and link to the full transcript or recording for audit.
* Map required fields before launch: destination object, owner, status, urgency, next step, and record URL.
* Create review paths for low-confidence matches, sensitive requests, high-value customers, and actions that change money, access, legal terms, or customer commitments.

## FAQs

<AccordionGroup>
  <Accordion title="What belongs in the audit trail?">
    Caller identity, requested action, reviewer, decision, timestamp, policy reason, DialNexa call ID, and links to restricted transcript or recording evidence.
  </Accordion>

  <Accordion title="How should suspicious callers be routed?">
    Tag the risk reason, avoid giving sensitive details, and notify the security or IT channel with the safe summary and evidence links.
  </Accordion>

  <Accordion title="What should stay out of Slack or CRM?">
    Secrets, recovery phrases, private keys, full transcripts, and detailed internal security reasoning should stay in restricted systems.
  </Accordion>

  <Accordion title="Should DialNexa ever store passwords or secrets here?">
    No. Store a safe summary, risk reason, and restricted evidence links. Do not write passwords, recovery codes, tokens, API keys, or private credentials into broad-access records.
  </Accordion>

  <Accordion title="When should a call become a security review?">
    Create a review when the caller asks for account recovery, admin access, permission changes, shared secrets, unusual exceptions, or anything that changes security posture.
  </Accordion>

  <Accordion title="How should identity confidence be handled?">
    Send the verification method, confidence level, failed checks, and reviewer requirement as separate fields so the security team can see why DialNexa did or did not proceed.
  </Accordion>

  <Accordion title="Can DialNexa trigger access changes directly?">
    Only for low-risk, pre-approved flows. Admin rights, emergency access, credential changes, and policy exceptions should require a human approval step.
  </Accordion>
</AccordionGroup>