[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69B93D9TK4SH22P4ZEAMR3J":3,"skill-same:01M69B93D9TK4SH22P4ZEAMR3J":105},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":20,"frontMatter":21,"refName":22,"commitSha":23,"skillDirectory":24,"forksCount":25,"repositoryHtmlUrl":26,"repositoryHomepageUrl":6,"ownerHtmlUrl":27,"ownerBlogUrl":28,"ownerDescription":29,"updatedAt":30,"install":31,"resources":44},"01M69B93D9TK4SH22P4ZEAMR3J","workday",null,"microsoft\u002FEmployee-Self-Service-Agent-Developer-Kit","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69B8MRC17NGDB6TFWV3247A",31,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002FSKILL.md",[],[5],"2026-11-10 10:12:30",false,"\u003C!-- Copyright (c) Microsoft Corporation. Licensed under the MIT License. -->\n\n# Connect Workday to the ESS HR agent\n\nThis branch is DA-only. CEA Workday Connect is maintained on `main-ca`; do not\nrun a CEA lifecycle or use CEA progress as evidence here.\n\nGuide the customer through one resumable Workday connection lifecycle per\nDEV, TEST, and PROD target. Use\n`scripts\u002Fworkday_connect.py` and\n`.local\u002Fconnect\u002Fworkday-da\u002Fconfig.json` internally; do not create, copy,\nupdate, or infer status from a Markdown checklist.\nUse `shared\u002Fconfig-schema.md` as the internal state and migration reference;\nit is not a customer-executed phase and must not be shown as an extra step.\n\n## Safety contract\n\n- Support only the active native ESS HR agent recorded by `\u002Fsetup`. Classic DA\n  and ESS IT agents are outside this lifecycle. The controller verifies the\n  exact agent, workspace materialization, architecture, and Dataverse\n  environment during preflight.\n- Never ask for a Workday password, client secret, access token, refresh token,\n  cookie, certificate private key, or certificate body in chat.\n- Explain an authentication prompt before launching it. PAC, Dataverse,\n  connector OAuth, and Agent Builder are separate credential stores; a prompt\n  for a different store is expected, but a valid store must not be prompted\n  twice for the same account and session. The guided Microsoft Entra phase\n  must not authenticate the maker to Graph.\n- Preview the exact target and actions before approval. After approval, verify\n  the plan hash immediately before every mutation. If discovery or scope\n  changes, discard the approval and show the new plan.\n- After every mutation, reread the target and persist evidence only after the\n  verified result matches the approved plan.\n- Never diagnose a permission problem from a guess. Show the API, CLI, or\n  checked-in script evidence that produced the diagnosis.\n- Use structured `vscode_askQuestions` forms for choices and short customer\n  evidence. The Entra and Workday administrator handoffs are the only\n  exception: share the checked-in workbook, collect the administrator's\n  full local path to the completed `.xlsx` file, and pass that file to the\n  controller's worksheet parser. Accept only the resulting validated structured payload.\n  Reject missing, duplicate, or unknown labels, formulas, and unsafe workbook\n  content; never infer an answer or treat a supplied path as evidence before\n  validation.\n- Leave every option initially unset. Do not add `recommended`, `default`,\n  “recommended” label text, or any equivalent preselection to approvals,\n  factual observations, connection choices, or validation outcomes. Continue\n  only after the customer explicitly submits a choice.\n- Reuse the exact recorded account through the shared credential cache. Run\n  only the narrow verification required for the current phase; do not launch\n  broader checks that request unrelated API audiences.\n\n## Customer-facing language contract\n\nCommands, file paths, JSON payloads, state keys, plan hashes, checkpoint IDs,\nschema names, component maps, API names, and implementation terms in this skill\nare internal execution instructions. Never show or narrate them unless the\ncustomer explicitly asks for technical diagnostics.\n\nCustomer-facing messages must describe only:\n\n- the customer-visible target and current phase;\n- who needs to perform a portal or Workday action;\n- the exact portal navigation and field value needed for that action;\n- whether a supported change or verification succeeded;\n- the concise remediation needed when it did not.\n\nKeep execution-only notes and action markers such as `A.1` and `B.2` internal.\nDo not turn later-phase sequencing rules into warnings about pages the maker\nhas not been asked to use. Show necessary safety guidance at the step where\nit applies, without repeating it in surrounding prose.\n\nTranslate internal outcomes into plain language. For example, say **all\nWorkday topics are enabled**, not that component `state` and `status` are\n`Active`. Topic metadata diagnostics are support context and must not be\ntranslated into a missing-package, missing-flow, or runtime-failure claim by\nthemselves. Never show `CloudFlow NotFound`, `MinimalBot`, component-map,\nnative-definition terminology, raw command output, tracebacks, encoding\nerrors, or internal identifiers in a customer message.\n\nRead `WORKDAY_CONNECT_RESULT_JSON` directly. Do not create an ad hoc Python or\nPowerShell formatter merely to render controller status. If an internal\nformatting command fails, correct or retry it internally and show only the\nvalidated customer-facing result.\n\n## Capability contract\n\nThis table is an internal reference, not an opening customer plan. Never\nrender it automatically on invocation; choose the applicable presentation\nunder **Start or resume** only after resolving the target realm and status.\n\nDescribe each action according to who actually performs it:\n\n| Phase                 | What the skill can do                                                                                                                                                                                                         | What remains a user or administrator action                                                                             |\n| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |\n| Preflight             | Verify the selected agent, environment, account, and supported Workday package choice without installing it                                                                                                                   | Complete Microsoft sign-in and choose an environment when no exact URL is known                                         |\n| Microsoft Entra       | Generate one guided administrator handoff, validate the returned non-secret target and configuration evidence, and record it                                                                                                  | Identify the exact application, create or change it in the portal, and return the requested evidence                    |\n| Workday administrator | Generate the handoff, validate returned non-secret values, derive endpoints, and record evidence                                                                                                                              | Change SAML, OAuth, API-client, certificate, or authentication-policy settings in Workday                               |\n| Connections           | After approval, install or verify the Workday package, then record the reviewed physical-connection readiness evidence                                                                                                        | Approve package installation, create connector connections, and complete connector OAuth                                |\n| Runtime               | After approval, bind the Workday connections, activate the package flows and configure required runtime permissions; author topic routing and enable Workday topics only in Development, and verify inherited topic state and wiring read-only in Test\u002FProduction | Connect flows to the agent and enable parameter sharing in Copilot Studio when those settings require maker interaction |\n| Maker validation      | Guide and record one successful pre-publish maker smoke test, then close the guided lifecycle                                                                                                                                    | Test once in the Copilot Studio Test pane without publishing                                                                                                         |\n\nNever say \"I changed,\" \"I configured,\" \"I enabled,\" or \"I updated\" for a\nmanual action. Say what the administrator or maker must do, then say what the\nskill can verify or record afterward. Claim an automated change only after its\ncommand succeeded and the target was reread.\n\n## Tenant foundation and deployment scope\n\nTreat the Entra and Workday configuration as a reusable tenant foundation.\nTreat package installation, physical connections, runtime flow wiring, native\ntopics, and maker validation as environment-and-agent-specific deployment\nwork. Publishing and non-maker validation happen after this guided lifecycle.\n\n- A different Power Platform environment, ESS HR agent, or maker account must\n  not by itself require the Entra or Workday administrators to repeat setup.\n- For a controller-verified Test or Production promotion in the same\n  AgentBuilder ALM family and Microsoft Entra tenant, reuse the recorded tenant\n  foundation and continue at Connections. The promoted target discovery is the\n  fresh target proof; do not repeat the Entra or Workday administrator handoff.\n- For an unrelated environment or any target that cannot be proven as the\n  promoted sibling, do not silently trust stored Entra evidence or perform a\n  maker-authenticated Graph reread. Keep setup blocked until the exact target\n  and tenant relationship can be verified.\n- Ask the administrator to repeat only missing, changed, or unhealthy settings.\n  Outside the verified promotion path, every fresh Entra sign-off must be\n  followed by fresh Workday administrator confirmation and a completed\n  workbook. Matching a saved tenant foundation does not complete that phase.\n  Healthy settings may be confirmed without repeating configuration changes.\n- Never reuse foundation evidence across a different Entra tenant, Workday\n  tenant, SAML Service Provider ID, Entra application, or signing certificate.\n- Keep the detailed administrator instructions in the workbook and internal\n  guide. In chat, show only the concise handoff, target values, workbook link,\n  and essential handoff notes. Do not repeat administrator task lists. On a\n  question or validation failure, show only the affected help or correction\n  instead of making the user repeat healthy configuration.\n\n## One-way administrator handoff\n\nTreat the two administrator phases as a one-way relay between different\npeople:\n\n1. Microsoft Entra sign-off must finish first, including transfer of the\n   active Base64 signing certificate through the customer's approved channel.\n2. Only then may the Workday administrator phase begin.\n3. The Workday handoff consumes the recorded Entra identifiers, certificate\n   metadata, and transferred certificate file. It must not ask the maker to\n   reopen Entra, re-engage the Entra app administrator, or repeat an Entra task.\n4. A Workday-side mismatch or uncertainty remains blocked in the Workday phase\n   and is resolved through the customer's Workday governance path. The only\n   exception is an explicit controller-detected change to the selected Entra\n   target, which invalidates downstream evidence before a new phase continues.\n\nDo not combine both administrator guides into one conversation handoff. Each\nadministrator receives only the standalone section for their phase.\n\n## DEV, TEST, and PROD journey\n\nUse `\u002Fconnect-workday` or `\u002Fconnect` with Workday selected for every realm.\nNatural-language statements such as **I promoted the agent to Test** or **the\nagent is now in Production** enter this same lifecycle. Do not introduce or\nsuggest realm-specific slash commands such as `\u002Fconnect-workday-test` or\n`\u002Fconnect-workday-prod`.\n\nOn every invocation, use the controller's `activeTargetRealm` and `targets`\nstatus. Never infer the active realm from conversation text alone.\n\nDistinguish a completed promotion from a request to perform promotion.\n**Promote the agent to Test** or **How do I promote?** is not evidence that\npromotion happened. Explain that Connect Workday configures Workday after\npromotion but does not promote or publish an agent. Open the source agent's\nknown Copilot Studio link, identify its current realm, and direct the maker\nresponsible for agent deployment to complete the organization's approved\npromotion process. Use documented native DA instructions when available;\nnever invent portal controls or substitute Dataverse solution export\u002Fimport\nor publishing for realm promotion.\n\nIf promotion completion is unknown, ask with `vscode_askQuestions`:\n\n```json\n[\n  {\n    \"header\": \"Promotion\",\n    \"question\": \"Has the agent already been promoted to the requested realm?\",\n    \"options\": [\n      { \"label\": \"Yes, promotion is complete - check again\" },\n      { \"label\": \"No, I need to complete promotion first\" },\n      { \"label\": \"Not now\" }\n    ],\n    \"allowFreeformInput\": false\n  }\n]\n```\n\nLeave the selection unset. On **Yes**, run the discovery below. On **No**,\nprovide the source-agent link and deployment-owner handoff above, then ask\nthe maker to return here after promotion. **Not now** preserves all progress.\nAn explicit statement that promotion completed already answers this question;\ndo not ask it again. Always finish with an actionable result or this decision,\nnot an empty response or internal-process narration.\n\n1. Complete DEV through the maker's successful Copilot Studio Test pane\n   scenario.\n2. After DEV is Ready, if the maker says the agent was promoted to Test or\n   chooses to configure Test, run automatic promoted-target discovery:\n\n   ```powershell\n   python scripts\u002Fworkday_connect.py discover-realm-target --realm test\n   ```\n\n3. If automatic discovery cannot prove one environment, show the safe\n   environment names or URLs returned by the controller and ask the maker to\n   select one. Leave the choice unset, then rerun with the selected friendly\n   value:\n\n   ```powershell\n   python scripts\u002Fworkday_connect.py discover-realm-target --realm test --environment \"{ENVIRONMENT_NAME_OR_URL}\"\n   ```\n\n4. After TEST is Ready, use the same flow for Production:\n\n   ```powershell\n   python scripts\u002Fworkday_connect.py discover-realm-target --realm prod\n   ```\n\n   Use `--environment` only when automatic discovery requests a selection.\n\nDo not ask the maker for an environment ID, BotId, flow ID, authorization team\nname, ALM family ID, or deployed commit. The controller obtains and verifies\nthose values. A URL is acceptable only as the maker's friendly environment\nselection when automatic proof is insufficient.\n\nPromoted-target discovery must prove the exact sibling realm, direct agent\nidentity, ALM family, supported schema, deployed commit, tenant, environment,\nand Dataverse URL. It then activates an independent realm snapshot and reuses\nthe verified tenant foundation. Package readiness, physical connections,\nruntime wiring, topics, and Maker validation remain target-specific and must\nbe completed separately in that active realm.\n\nIf discovery reports `foundationReused: true`, continue at Connections without\nshowing either administrator phase. If it is false, do not claim the\nfoundation was reused; follow the controller's current phase and blocker.\n\nDiscovery may find the sibling in the same Power Platform environment as\nDev. Do not ask the maker to create a separate environment just because its\nrealm is Test or Production. The controller still verifies the exact sibling,\nrealm, tenant, and ALM family.\n\nIf discovery fails, preserve the active realm and all completed administrator\nwork. Show the observed failure and the returned remediation. Offer **Check\nagain**, **Choose another environment**, and **Not now** in an unset\n`vscode_askQuestions` form. Reuse a supplied valid environment selection on\n**Check again**; ask for a friendly name or Dataverse URL only on **Choose\nanother environment** or when no selection exists. A malformed unrelated\ninventory entry is not evidence that the maker supplied an invalid GUID.\nDo not send the maker to reinstall tooling, repeat administrator handoffs,\nor contact support without first offering the applicable retry\u002Faccess steps.\n\n## Start or resume\n\nRun status before showing any plan, role table, progress table, phase\nexplanation, or participant question:\n\n```powershell\npython scripts\u002Fworkday_connect.py status\n```\n\n### Resolve the realm and completion before presenting a plan\n\nIf this invocation carries an explicit promotion intent, use the returned\ntarget registry before the normal ready-state completion branch or any\nbriefing:\n\nIf promotion completion is unknown, use the **Promotion** decision above\nbefore proceeding. Do not show an opening plan while that decision or\npromoted-target verification is outstanding.\n\n- For a confirmed completed Test promotion, require the DEV target to be `ready`, then run\n  `discover-realm-target --realm test`.\n- For a confirmed completed Production promotion, require the TEST target to be `ready`, then run\n  `discover-realm-target --realm prod`.\n\nIf the prerequisite realm is not Ready, keep that realm active and explain\nthat its Maker validation must finish before configuring the next realm.\nShow only its current unfinished phase, not a new opening plan. If discovery\nsucceeds, run `status` again and use the newly verified `activeTargetRealm`,\n`targets`, `phases`, and `nextPhaseId` for every subsequent message. Do not\nrender the previous realm's progress or completion first. If discovery fails\nor requires a target selection, use the recovery or selection in **DEV, TEST,\nand PROD journey** and do not show a speculative Test or Production plan.\n\nIf controller status is `ready` after resolving any explicit promotion intent,\ngo directly to **Completion** and finish this invocation. Do not show the\nopening role table, `progressText`, a phase plan, or a participant question.\nA bare Connect request after Development is Ready does not restart Development\nor establish that promotion occurred. Do not discover or activate the next\nrealm without the maker's explicit intent.\n\nFor a non-ready lifecycle, require a resolved `activeTargetRealm` from the\ncontroller before choosing a plan. Do not infer Test or Production solely\nfrom the maker's wording, or fall back to a Development plan when the target\ncannot be verified. Show the actual target blocker and supported recovery.\n\n### Choose the presentation for the verified realm\n\n- **First Development start:** Only when `activeTargetRealm` is `dev`, the\n  lifecycle is not ready, all phases are still pending, and no administrator\n  evidence has been captured, use the first-start briefing below. Any\n  completed, in-progress, or blocked phase makes this a resume. Do not repeat\n  the briefing within the same conversation even if all phases remain pending.\n- **Development resume:** On resume, show the current phase and only its\n  remaining participants, with the current six-phase progress table as\n  described below; do not repeat the full role table or completed\n  administrator handoffs.\n- **Verified Test or Production:** Show a concise **Workday connection plan -\n  Test** or **Workday connection plan - Production** only after that realm\n  has been resolved by the controller. Build a short list from that active\n  realm's `phases`, including only phases whose `status` is not `complete`.\n  Never show the Development opening briefing, capability table, or six-row\n  `progressText`, even on the first invocation for that promoted target.\n  On a later invocation, narrow this list to the still-unfinished work.\n\nFor a verified promotion with `foundationReused: true`, explain once that the\nexisting tenant foundation is reused. The remaining plan contains only\nunfinished **Connections**, **Runtime configuration**, and **Maker validation**\nfor this Test or Production agent. Describe target-specific package and\nconnection readiness, runtime authorization and sharing, and the maker Test\npane validation. Do not include completed Preflight or administrator phases,\nask administrators to repeat their handoffs, or imply Development is being\nconfigured again. Development's completed connection remains unchanged.\nTopic enabling and the refreshed-page **Confirm Workday topics** question\nbelong only to Development. In Test and Production, preserve the promoted\nenabled\u002Fdisabled states and use read-only verification without either topic\nactivation question. Connection binding, parameter sharing, and realm-specific\nauthorization remain required.\n\nIf the controller instead reports a foundation blocker or an unfinished\nadministrator phase, show that exact phase and required remediation for the\nverified realm. Do not claim reuse or promise the three-phase promoted plan\nuntil the controller confirms it. Do not replace a real blocker with the\ngeneric six-phase Development plan.\n\n### First Development start only\n\nOn the first start of a non-ready Development lifecycle, show this readiness\nbriefing only after the realm and completion decisions above:\n\n> Here's who may be needed to connect Workday to your ESS HR agent:\n>\n> | Phase                 | Responsibility                                                                                                                                             | Who is needed                                                                                                        |\n> | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |\n> | Preflight             | Verify the ESS HR agent, environment, maker account, and supported package choice without changing the environment                                         | Power Platform Environment Maker                                                                                     |\n> | Microsoft Entra       | Configure the Workday enterprise application, SAML, API permission, consent, assignment, and NameID                                                        | One Microsoft Entra app administrator with either the Application Administrator or Cloud Application Administrator role; involve a separate consent-capable administrator only if tenant policy prevents that administrator from granting consent |\n> | Workday administrator | Configure tenant SAML and certificate trust, OAuth and the API client, functional-area access, endpoints, and the employee authentication policy           | Workday Administrator                                                                                                |\n> | Connections           | Install or verify the Workday package, then connect Microsoft Dataverse and Workday                                                                         | Power Platform Environment Maker with package installation access                                                    |\n> | Runtime configuration | Connect the installed Workday components, activate the required flows, configure runtime permissions and connection sharing, and enable all Workday topics | Power Platform Environment Maker; Dataverse System Administrator access for runtime authorization                    |\n> | Maker validation      | Test a read-only Workday request in the Copilot Studio Test pane                                                                                            | Environment Maker |\n>\n> I'll run the available checks and automate supported changes. Each\n> administrator gets a workbook with the required steps. Workday setup\n> finishes after your Workday test succeeds in the Copilot Studio Test pane.\n\n### Continue the current unfinished phase\n\nThe controller runs automatic readiness checks at the relevant phase\nboundaries. Present only the resulting customer-safe readiness\nor remediation state; do not expose internal profile\u002Fcheckpoint identifiers or\nask the customer to run a second validation workflow.\n\nFor a resolved, non-ready lifecycle, after the applicable presentation:\n\n1. **Development progress rule:** For a verified, non-ready\n   `activeTargetRealm: dev`, render the returned `progressText` as Markdown\n   on entry or resume and whenever `nextPhaseId` changes, before the current\n   phase explanation or participant questions. This includes transitions to\n   `entra` and `workday-admin`, not only Preflight. After completing a phase,\n   run `status` again before presenting the next phase; do not reuse the\n   previous phase's progress snapshot. It is the visible six-row roadmap and\n   must not be collapsed into a one-line phase list. Do not repeat it for\n   every question, file-path request, or workbook correction within an\n   unchanged phase unless the maker asks for progress. Omit it for a ready\n   lifecycle and Test or Production plans.\n2. Render the returned `nextPhaseSummary` in this form:\n\n   ```markdown\n   ### Current phase: {title}\n\n   What happens in this phase:\n\n   - {whatHappens item 1}\n   - {whatHappens item 2}\n   - {whatHappens item 3}\n   ```\n\n3. Show new customer-safe `readiness.summary` results as they occur. On resume,\n   show only evidence relevant to the current unfinished phase or its blocker,\n   not a recap of every completed phase. Do not expose profile or checkpoint\n   identifiers.\n4. Show the current blocker afterward when one is present. Use its `summary`\n   and `nextAction`; do not render any other blocker fields.\n\nDo not render internal action IDs, hashes, or the full JSON state. Do not\nreplace the phase explanation with only `Current phase: {title}`.\n\nFor a non-ready lifecycle, determine the current phase's required participants\nfrom `nextPhaseId`:\n\n| `nextPhaseId`         | People required for the current phase                                                                                                                                                                       |\n| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `preflight`           | Power Platform Environment Maker                                                                                                                                                                            |\n| `entra`               | One Microsoft Entra app administrator with either the Application Administrator or Cloud Application Administrator role to complete the handoff; involve a separate consent-capable administrator only if tenant policy prevents that administrator from granting consent |\n| `workday-admin`       | Workday Administrator                                                                                                                                                                                       |\n| `connections`         | Power Platform Environment Maker with package installation access                                                                                                                                           |\n| `runtime`             | Power Platform Environment Maker with Dataverse System Administrator access for runtime authorization                                                                                                       |\n| `maker-validation`    | Environment Maker                                                                                                                                                                                           |\n\nWhen `nextPhaseId` is `entra`, dispatch to `provision-entra-app.md` without the\nform below. That phase asks whether the maker has engaged the administrator,\npresents a concise handoff and checked-in detailed workbook, asks whether the\nadministrator completed the task, and validates the workbook at the supplied\npath. It must not authenticate the maker to Graph or perform live Entra API checks.\n\nWhen `nextPhaseId` is `workday-admin`, show only its row and use this exact\n`vscode_askQuestions` form before dispatching that phase:\n\n```json\n[\n  {\n    \"header\": \"Workday administrator\",\n    \"question\": \"Have you arranged for a Workday administrator to complete this step?\",\n    \"options\": [\n      { \"label\": \"Yes, the Workday administrator is engaged\" },\n      { \"label\": \"No, I still need to engage the Workday administrator\" }\n    ],\n    \"allowFreeformInput\": false\n  }\n]\n```\n\nWhen `nextPhaseId` is `preflight` or `runtime`, show only its row and use this\nexact `vscode_askQuestions` form before dispatching that phase:\n\n```json\n[\n  {\n    \"header\": \"Required access\",\n    \"question\": \"Are the people listed for this step available to help?\",\n    \"options\": [\n      { \"label\": \"Yes, required people are available\" },\n      { \"label\": \"No, someone is unavailable\" }\n    ],\n    \"allowFreeformInput\": false\n  }\n]\n```\n\nWhen `nextPhaseId` is `connections`, show only its row and use this exact\n`vscode_askQuestions` form before dispatching that phase:\n\n```json\n[\n  {\n    \"header\": \"Connections access\",\n    \"question\": \"Do you have Power Platform Environment Maker access and permission to install the Workday package in this environment?\",\n    \"options\": [\n      { \"label\": \"Yes, I have the required privilege and access\" },\n      { \"label\": \"No, I do not have the required privilege or access\" }\n    ],\n    \"allowFreeformInput\": false\n  }\n]\n```\n\nWhen `nextPhaseId` is `maker-validation`, show only its row and use this exact\n`vscode_askQuestions` form before dispatching that phase:\n\n```json\n[\n  {\n    \"header\": \"Test access\",\n    \"question\": \"Do you have Environment Maker access to test this agent in the Copilot Studio Test pane?\",\n    \"options\": [\n      { \"label\": \"Yes, I have the required privilege and access\" },\n      { \"label\": \"No, I do not have the required privilege or access\" }\n    ],\n    \"allowFreeformInput\": false\n  }\n]\n```\n\nLeave every selection unset. The Connections and Maker validation answers are\nprivilege self-attestations for routing; the Preflight and Runtime answer is an\navailability self-attestation. None is proof that the signed-in account has\nthe required role. The phase-specific live checks or structured administrator\nevidence remain authoritative.\n\nAfter the maker confirms the Workday administrator is engaged, the Workday\nphase shares the checked-in detailed workbook with concise target values and\nthe applicable federation safety note, not another administrator task list.\nIt tells the maker to have the administrator follow and complete the workbook,\nasks whether the task is complete, then requests the full local path to the\ncompleted `.xlsx` file. It must not require an upload or ask the maker to paste\nthe worksheet table or retype the administrator values.\nDo not include people from completed phases or remediation-only roles that are\nnot currently required. In particular, require the Workday Administrator only\nwhen `nextPhaseId` is `workday-admin`; a healthy reused tenant foundation\non a controller-verified Test or Production promotion continues at Connections\nwithout that role. A regular Entra workbook return must not take this shortcut.\n\nIf the maker selects a negative administrator-engagement option, stop before\ndispatching the next phase and ask them to return when that administrator can\nparticipate. If the maker selects a negative maker-privilege option, stop and\nask them to return after the required privilege or access is granted, or to\nrerun the skill using the authorized maker account. If the maker selects the\nnegative generic availability option, ask them to return when the required\npeople are available. In every case, explain that no phase progress or target\nconfiguration was changed. Do not request a person's name, credentials, or\nother identifying information, and do not offer to bypass the role\nrequirement.\n\nIf the maker selects either affirmative option, dispatch the next phase below.\nWithin the same invocation, do not repeat the question while `nextPhaseId`\nremains unchanged. After a phase completes and `status` returns a different\n`nextPhaseId`, evaluate and ask for that new phase.\n\nDispatch from `nextPhaseId`:\n\nPreflight dispatch is foundation-only: use the Preflight guide only for Setup's\ninitial Development target. For an active Test or Production target, do not\nrun `preflight` as a general prerequisite repair or recheck. Preserve its active\nrealm, scope, and phase evidence; use promoted-target discovery or the current\nphase's supported recovery. If no target-preserving recovery is available,\nshow the exact blocker and stop rather than resetting the target.\n\n- `preflight` -> read `install-extension.md`\n- `entra` -> read `provision-entra-app.md`\n- `workday-admin` -> read `configure-tenant.md`\n- `connections` or `runtime` -> read `configure-power-platform.md`\n- `maker-validation` -> read `verify-connection.md`\n\nWhen a phase returns, run `status` again and continue from the controller's\nnext phase. Never restart completed phases because the user asked a side\nquestion; answer the side question, then resume the same blocker.\n\n## Completion\n\nOnly after controller status is `ready`, render the returned\n`completionMessage`. Status and maker-validation completion return the same\nrealm-specific completion: Workday Connect is complete, the maker Test pane\nvalidation passed, and no further Workday Connect action is required in that\nrealm. Do not describe reused administrator prerequisites as steps performed\nagain in Test or Production or claim that all six steps were performed there.\n\nDo not append routine recaps of Development readiness, administrator handoffs\nor preserved sign-offs. Preserve that evidence internally; discuss it only\nwhen the maker asks or an actual blocker requires it.\n\nFinish using **Finish the current Workday connection** in\n`verify-connection.md`. Do not invoke Setup between phases or at completion;\nits prerequisite handoff belongs only to `entry.md`, before this lifecycle\nstarts. Do not ask the maker to run Connect again for this completed realm.\n\nRender `postSkillNextSteps`\nunder **Optional next steps**. These are\nfuture deployment choices, not continued actions or another required phase.\nLink to the known source agent in Copilot Studio for manual promotion, and\nmake the deployment-owner responsibility explicit. Do not start promotion or\nanother realm without an explicit maker request.\n\nDo not tell a DEV maker to perform Production release validation, and do not\noffer Production until TEST is Ready. Do not claim that a maker Test pane\nsuccess independently verifies published employee scenarios.\n",{},"main","a1b1bbb8aaa2435985ea2242cf836acf31b8a390","solutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday",19,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-13 08:32:39",{"source":7,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add microsoft\u002FEmployee-Self-Service-Agent-Developer-Kit --skill workday",{"tool":37,"command":38},"bunx","bunx skills add microsoft\u002FEmployee-Self-Service-Agent-Developer-Kit --skill workday",{"tool":40,"command":41},"pnpm","pnpm dlx skills add microsoft\u002FEmployee-Self-Service-Agent-Developer-Kit --skill workday","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002FSKILL.md",true,[45,51,55,59,65,69,73,77,81,85,89,93,97,101],{"path":46,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":49,"sourceHtmlUrl":50},"actions\u002Factivate-workday-topics.md","REFERENCE","参考文档",5970,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002Factions\u002Factivate-workday-topics.md",{"path":52,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":53,"sourceHtmlUrl":54},"actions\u002Fwire-runtime-template-config.md",6373,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002Factions\u002Fwire-runtime-template-config.md",{"path":56,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":57,"sourceHtmlUrl":58},"actions\u002Fwire-user-context-redirect.md",5022,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002Factions\u002Fwire-user-context-redirect.md",{"path":60,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":63,"sourceHtmlUrl":64},"assets\u002Fentra-admin-workbook.xlsx","ASSET","资产文件",13039,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002Fassets\u002Fentra-admin-workbook.xlsx",{"path":66,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":67,"sourceHtmlUrl":68},"assets\u002Fworkday-admin-workbook.xlsx",10606,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002Fassets\u002Fworkday-admin-workbook.xlsx",{"path":70,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":71,"sourceHtmlUrl":72},"configure-power-platform.md",27842,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002Fconfigure-power-platform.md",{"path":74,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":75,"sourceHtmlUrl":76},"configure-tenant.md",35746,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002Fconfigure-tenant.md",{"path":78,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":79,"sourceHtmlUrl":80},"entry.md",7328,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002Fentry.md",{"path":82,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":83,"sourceHtmlUrl":84},"install-extension.md",9224,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002Finstall-extension.md",{"path":86,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":87,"sourceHtmlUrl":88},"integration.json",222,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002Fintegration.json",{"path":90,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":91,"sourceHtmlUrl":92},"provision-entra-app.md",21028,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002Fprovision-entra-app.md",{"path":94,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":95,"sourceHtmlUrl":96},"shared\u002Fconfig-schema.md",13871,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002Fshared\u002Fconfig-schema.md",{"path":98,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":99,"sourceHtmlUrl":100},"status.md",1181,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002Fstatus.md",{"path":102,"resourceType":47,"resourceTypeDesc":48,"sizeBytes":103,"sourceHtmlUrl":104},"verify-connection.md",7026,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fworkday\u002Fverify-connection.md",[106,114,121,128,136,142],{"skillNo":107,"name":108,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":18},"01M6PJDNK6N62M11V5WPFY8PK0","servicenow-da","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fservicenow-da\u002FSKILL.md",[],[112,113],"servicenow","servicenow da",{"skillNo":115,"name":116,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":18},"01M6PJDHJHJYWRPB3NFKY8J7SY","servicenow-da-itsm","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fservicenow-da-itsm\u002FSKILL.md",[],[112,120],"servicenow da itsm",{"skillNo":122,"name":123,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":18},"01M6PJD93VBG12YV42JC80VTQJ","servicenow-da-hrsd","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fconnect\u002Fservicenow-da-hrsd\u002FSKILL.md",[],[112,127],"servicenow da hrsd",{"skillNo":129,"name":130,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":18},"01M69BAFGZ25JSN9W1GMP16NHD","ESS-Diagnostics-Skills","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Ftools\u002FESS-Diagnostics-Skills\u002FSKILL.md",[],[134,135],"diagnostics","ESS Diagnostics Skills",{"skillNo":137,"name":138,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":141,"publishedAt":18},"01M69BADVK3HC5BCARHN74EEGJ","update","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fworkflows\u002Fupdate\u002FSKILL.md",[],[138],{"skillNo":143,"name":144,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":152,"publishedAt":18},"01M69BAC4GJCHR0MS5DWEK5JRC","test","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FEmployee-Self-Service-Agent-Developer-Kit\u002Fblob\u002Fmain\u002Fsolutions\u002Fess-maker-skills\u002Fsrc\u002Fskills\u002Fworkflows\u002Ftest\u002FSKILL.md",[147],{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[144]]