nexus-mcp/archive/Workday/Planning/workday-cross-team-conversation-playbook.md

---
title: "Workday to AD sync — cross-team conversation playbook"
description: "Detailed prep and conversation guide for closing Workday access, security, connectivity, and compliance prerequisites."
type: "Execution Playbook"
version: "v1"
author: "N. Castaldi"
date: "2026-04-03"
status: "DRAFT"
---

## Purpose

Use this playbook to run focused conversations with each stakeholder group so prerequisites are closed quickly and in the right sequence.

## Core outcomes to close

- Confirm the right Workday data fields we are approved to use.
- Provision non-prod API access and integration credentials.
- Approve auth/token and least-privilege scope.
- Confirm secrets handling and runtime connectivity path.
- Validate privacy/compliance guardrails on allowed vs restricted attributes.

## Recommended sequence

1. HRIS/Workday owner (field and business-rule alignment)
2. Workday integration admin (API enablement and credentials)
3. Security/IAM (auth and access approval)
4. Platform/IT operations (secrets and runtime path)
5. Compliance/privacy (data handling validation)

## Global prep package (have ready before any meeting)

- Project one-liner: what problem is being solved and expected operational value.
- Scope boundaries: read-only non-prod pilot first; no write/remediation in initial phase.
- High-level workflow: Workday source data -> MCP read tools -> mismatch reporting.
- Target timeline: requested decision date and target pilot start date.
- Draft field list: requested attributes and intended usage for each.
- Architecture summary: where code runs, how credentials are stored, who can access logs.
- Risk controls summary: least privilege, redaction, audit logging, approval gates.
- Decision log template: owner, decision, date, follow-up tasks.

## Team-by-team conversation guide

## HRIS / Workday functional owner

### Objective

Confirm business semantics and approved fields so downstream technical setup is based on correct policy and definitions.

### You need to have ready

- Draft list of required worker attributes and why each is needed.
- Proposed source-of-truth assumptions (status, manager, effective dates).
- Examples of mismatch scenarios the process needs to detect.
- Definition of out-of-scope fields for phase 1.

### You need to ask them

- Which exact fields are approved for this use case?
- Which fields are restricted or require additional approvals?
- What are the authoritative business rules for worker status transitions?
- Are there known edge cases (contractors, leaves, future hires) we must handle?
- Who is final approver for field-level usage decisions?

### Expected outputs

- Approved field allowlist.
- Explicit denylist/restricted-field list.
- Confirmed business-rule references and data definitions.
- Named functional approver.

## Workday integration administrator

### Objective

Enable non-prod API connectivity and provide integration credentials aligned to approved field scope.

### You need to have ready

- Approved field allowlist from HRIS discussion.
- Required endpoint list mapped to planned tools.
- Environment details for where integration will run.
- Requested timeline for first non-prod connectivity test.

### You need to ask them

- Which non-prod endpoint base URLs should be used?
- What auth mechanism is supported for this integration pattern?
- What integration client/account needs to be created?
- What scopes/permissions are required to support approved fields only?
- What are token TTL, refresh behavior, rate limits, and expected error patterns?
- Who owns credential rotation and break-glass procedures?

### Expected outputs

- Non-prod API endpoint details.
- Integration account/client provisioned.
- Initial credentials or secure retrieval path.
- API constraints documented (timeouts, throttling, limits).

## Security / IAM

### Objective

Approve authentication model, token lifecycle, and least-privilege access boundaries before runtime connection is enabled.

### You need to have ready

- Proposed auth flow and token lifecycle design.
- Requested scopes and rationale tied to allowlisted fields.
- Role and access matrix (who can access secrets/logs/runtime).
- Incident handling approach for auth failures.

### You need to ask them

- Does the proposed auth/token approach meet policy?
- Are requested scopes minimal and compliant?
- What are mandatory controls for token rotation and revocation?
- What logging or audit evidence is required for periodic review?
- What security sign-off is required before pilot launch?

### Expected outputs

- Auth model approved or revised with clear action items.
- Scope approvals documented.
- Token governance requirements confirmed.
- Security sign-off owner identified.

## Platform / IT operations

### Objective

Confirm where and how secrets are managed and verify runtime network/connectivity path for non-prod calls.

### You need to have ready

- Proposed runtime host/environment details.
- Secret storage options and preferred approach.
- Connectivity requirements (egress destinations, DNS, firewall needs).
- Operational support expectations (monitoring, alerting, on-call routing).

### You need to ask them

- Which secret manager/process is approved for this workload?
- How should credentials be injected at runtime?
- What network rules are required to reach non-prod Workday endpoints?
- What observability minimums are required for production readiness?
- What is the escalation path for connectivity or runtime failures?

### Expected outputs

- Approved secret handling pattern.
- Confirmed runtime connectivity path and network changes.
- Logging/monitoring baseline requirements.
- Platform support owner and escalation model.

## Compliance / privacy

### Objective

Validate that data usage, storage, logging, and retention patterns meet privacy and compliance requirements.

### You need to have ready

- Approved allowlist and denylist.
- Data flow summary showing where attributes are read, transformed, and stored.
- Logging and redaction plan.
- Retention and deletion approach for reports/log artifacts.

### You need to ask them

- Are approved attributes compliant for this use case?
- Are any attributes subject to heightened controls?
- What retention period and deletion controls are required?
- What masking/redaction standards are required in logs and reports?
- Is a formal privacy review or exception request required?

### Expected outputs

- Compliance disposition for field usage.
- Required privacy controls documented.
- Retention requirements confirmed.
- Named compliance approver and any follow-up tasks.

## Meeting cadence and format

- Format: 30-minute focused decision sessions.
- Cadence: run in sequence within one week.
- Artifacts: update decision log immediately after each session.
- Escalation: unresolved decision over 3 business days escalates to project sponsor.

## Suggested tracking table

| Workstream | Owner | Decision due | Current status | Blocker | Next action |
| --- | --- | --- | --- | --- | --- |
| Field allowlist/denylist | Unassigned | TBD | READY | None | Schedule HRIS review |
| Non-prod API credentials | Unassigned | TBD | READY | None | Confirm integration admin owner |
| Auth/token and scope approval | Unassigned | TBD | READY | None | Schedule IAM review |
| Secrets and connectivity path | Unassigned | TBD | READY | None | Confirm platform review participants |
| Privacy/compliance validation | Unassigned | TBD | READY | None | Share data-flow summary |

## References

- [workday-ad-identity-sync-next-steps.md](workday-ad-identity-sync-next-steps.md)
- [workday-ad-identity-sync-sprint-board.md](workday-ad-identity-sync-sprint-board.md)
- [workday-mcp-implementation-plan.md](workday-mcp-implementation-plan.md)