> ## 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.

# IBM X-Force Exchange

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

IBM X-Force Exchange is a threat intelligence sharing platform for researching security threats, aggregating intelligence, and collaborating on cybersecurity insights.

<Note>
  Use IBM X-Force Exchange with DialNexa when the caller asks for access, recovery, permission changes, vault help, or anything that could expose sensitive systems.
</Note>

## Where IBM X-Force Exchange fits in a DialNexa workflow

IBM X-Force Exchange 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="Keep secrets out of notes" icon="check-circle">
    Store a safe summary and links to restricted evidence instead of writing passwords, tokens, keys, or recovery codes.
  </Card>

  <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 IBM X-Force Exchange

* 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 IBM X-Force Exchange workflows

<AccordionGroup>
  <Accordion title="A suspicious caller repeats failed verification attempts">
    For this scenario, DialNexa should treat IBM X-Force Exchange 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 IBM X-Force Exchange 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 IBM X-Force Exchange 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 IBM X-Force Exchange.
  </Accordion>

  <Accordion title="Support needs identity confirmation before sharing private details">
    For this workflow, DialNexa should send IBM X-Force Exchange 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 caller mentions leaked credentials or phishing">
    For this workflow, DialNexa should send IBM X-Force Exchange 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 IBM X-Force Exchange 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 generate api key and password">
    Use generate api key and password 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 get user profile information">
    Use get user profile information before answering, routing, or creating follow-up. DialNexa should verify the lookup result against the caller and send low-confidence matches to a human queue.
  </Accordion>
</AccordionGroup>

## Workflows that pair IBM X-Force Exchange with other integrations

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

## Implementation notes

* Use the DialNexa call ID as the idempotency key before running IBM X-Force Exchange actions.
* Write a short operational summary into IBM X-Force Exchange 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="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>

  <Accordion title="What should happen after failed verification?">
    Stop the account-changing workflow, create a restricted review item, and include the attempted request, failed checks, call ID, and escalation owner.
  </Accordion>

  <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>
</AccordionGroup>