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

title, description, type, version, author, date, status

title	description	type	version	author	date	status
Workday to AD sync — cross-team conversation playbook	Detailed prep and conversation guide for closing Workday access, security, connectivity, and compliance prerequisites.	Execution Playbook	v1	N. Castaldi	2026-04-03	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-sprint-board.md
• workday-mcp-implementation-plan.md