HR & People package

Workday worker change → access update

A Workday job change, org move or termination maps old and new jobs to access bundles, logs the request, and the manager approves or rejects it.

Connects to Workday

OfficialHeadless / APIIntermediate~20 min setupv1.0.0
Download .utpkg 18 KBHow to install

About this package

What it does

Workday worker change → access update keeps access in step with the job. When a Job Change, organization move or Termination completes in Workday, the event is posted to the workflow with the worker id and event id.

The workflow reads the worker and their staffing history from the Workday Staffing REST API, so it knows the job profile and supervisory organization before and after the change. The Access bundle mapping decision table turns each into a bundle code (terminations map to no access), and the Access bundles table says which applications and groups each bundle grants.

When the bundle changes, an access change request is logged and the manager gets a task form with the bundles to remove and add, a bundle lookup to correct it, a remove-by date and Approve / Reject buttons. The decision is written to the Access change requests table and posted as a comment on the Workday business process event. Provisioning in your identity system can then pick up the approved rows.

Headless / API

Starts when Workday posts a worker change (worker id, event type, event id) to the workflow start API or inbound webhook from a business process notification or integration.

Another system starts it over REST or an inbound webhook. No UI is needed; people only appear where a decision needs a human.

The flow

Step by step

  1. 1

    Worker change

    Workday posts the worker id, event type (job_change, org_move, termination) and the event id.

  2. 2

    Before and after

    Get worker and Get worker job history give the current and previous job profile and organization.

  3. 3

    Map to bundles

    The Access bundle mapping decision table picks the old and new bundle; Access bundles lists what each grants.

  4. 4

    Log the request

    If the bundle changes, an access change request row is created; if not, the run ends.

  5. 5

    Manager decision

    The manager reviews the removals and additions on a task form and approves or rejects.

  6. 6

    Back to Workday

    The decision updates the request row and is posted as a comment on the Workday event.

Workday worker change access update — A Workday job change, org move or termination maps the old and new job to access bundles, logs the change request and has the manager approve it; the decision is posted back to the Workday event. The same canvas you get in the designer after installing.

Forms

Inputs and task forms

The inputs a caller passes when it starts a run, and the forms people complete when the process needs a decision.

Start inputs

Workday worker change access update

Passed by the calling system

Workday worker id * worker_id · textWorkday worker WID from the change event
Event type * event_type · select
job_changeorg_movetermination
job_change, org_move or termination
Business process event id * event_id · textWorkday event WID: the decision is posted back to it as a comment
Manager (user id) manager_user_id · textOptional: UserTasks user id of the approving manager; the install-time default receives the step otherwise

User Task

Manager approves access change

Approve access change for {{worker_name}}: {{from_bundle}} → {{to_bundle}} · 2-column grid · own header and theme

Remove bundle remove_bundle · textPrefilled: {{from_bundle}}
Add bundle * add_bundle · lookupPrefilled: {{to_bundle}}
Grants add_applications · textarea
Remove old access by * remove_by · datePrefilled: {{effective_date}}
Keep old access during handover keep_temporarily · boolean
Comment (posted to Workday) comment · textarea
ApproveReject

Headless

Call it from your systems

Every workflow can be started over REST, MCP or the CLI, whatever its trigger, with the sample input below. Runs start straight away on the published version; replace <workflow id> with the id the install created.

REST

shell
curl -X POST "$USERTASKS_URL/api/v1/workflows/start" \
  -H "Authorization: Bearer $USERTASKS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"workflow_id":"<workflow id>","variables":{"worker_id":"8d2f6e1a4b7c4e0f9a3d5c7b1e2f4a6c","event_type":"job_change","event_id":"e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6"}}'

CLI

shell
usertasks workflows inputs <workflow id>          # the start form: keys, types, required
usertasks workflows run <workflow id> --input worker_id=8d2f6e1a4b7c4e0f9a3d5c7b1e2f4a6c --input event_type=job_change --input event_id=e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6 --wait

Inbound webhook

shell
usertasks webhooks create <workflow id>          # prints the hook slug and secret once
curl -X POST "$USERTASKS_URL/api/webhooks/inbound?hook=<slug>" \
  -H "Authorization: Bearer <webhook secret>" -H "Content-Type: application/json" \
  -d '{"worker_id":"8d2f6e1a4b7c4e0f9a3d5c7b1e2f4a6c","event_type":"job_change","event_id":"e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6"}'

What's included

8 assets, ready to adapt

TypeNameDetails
Data tableAccess bundlesRole-based access bundles: which applications and groups each bundle grants, its risk and who owns it. The decision table picks a bundle code; this table says what it contains.
Data tableAccess change requestsEvery access change raised from a Workday worker change: bundles added and removed, the manager decision and when it was posted back to Workday.
IntegrationWorkday
API referenceAdd business process commentPOST /api/businessProcess/v1/acme/events/{{event_id}}/comments — Workday Business Process REST: add a comment to the worker change event so the access decision is visible on the business process in Workday.
API referenceGet workerGET /api/staffing/v6/acme/workers/{{worker_id}} — Workday Staffing REST: the worker as they are now (after the change): job profile, family, supervisory organization, manager and status.
API referenceGet worker job historyGET /api/staffing/v6/acme/workers/{{worker_id}}/history — Workday Staffing REST: the worker's staffing events, newest first. data[0] is the change that just happened, data[1] the job before it.
Decision tableAccess bundle mapping7 rules — Which access bundle a job profile and organization should have. Run once for the new job and once for the previous one. First matching rule wins.
WorkflowWorkday worker change access update24 steps — A Workday job change, org move or termination maps the old and new job to access bundles, logs the change request and has the manager approve it; the decision is posted back to the Workday event.

Access bundles · 7 sample rows

Bundle codeNameApplicationsDirectory groupsRiskOwner team

Access change requests · 1 sample rows

Change referenceWorkday worker idWorkerEventEffectiveRemove bundleAdd bundleRemove byDecisionDecided by (user id)StatusNotes

Requirements

What you connect it to

Credentials never travel in a package. The install wizard asks for what your environment must provide, or installs it incomplete until you finish setup.

Needs

  • REST API — A REST API integration: set its base URL and credentials on install.
  • Assignees — People in your workspace to receive the User Tasks (picked on install).
  • Inbound webhook — An inbound webhook created for the workflow, so other systems can start it.

After installing

  1. Workday integration: base URL https://<services-host>/ccx and an OAuth 2.0 bearer token for an Integration System User with Staffing and Business Process domain access. Replace "acme" in the reference paths with your tenant.
  2. Assignees: pick the default approving manager (runs can pass manager_user_id).
  3. Point Workday at the start API: a notification or integration subscribed to Job Change, Change Organization Assignments and Termination posts {"worker_id", "event_type", "event_id"}.
  4. Edit the Access bundles rows and the Access bundle mapping rules to match your roles; connect your identity system to the approved rows of Access change requests.

Asked for on install

  • Integration “Workday”Required

    • Tokenconfig.auth_config.token
    • Base urlconfig.base_urldefault https://wd-impl.workday.example.com/ccx· optional

  • Workflow “Workday worker change access update” assigneesRequired

    • User for step “Manager approves access change”nodes.16.config.assignee_id

Install

Install it in your workspace

Works on UserTasks cloud and on any self-hosted instance. Installing creates the assets above; nothing runs until you complete setup and start it.

In the app

  1. Download workday-worker-change-access-1.0.0.utpkg.
  2. Open Automations → Packages and drag the file onto the page (or choose Import package). Browse gallery there lists every gallery package without downloading by hand.
  3. Pick the file. The wizard verifies the checksum, every file hash and the signature, and shows the readme.
  4. Review the changes (what is created) and the data rows.
  5. Fill in the requirements, or tick Keep incomplete and finish later with Complete setup.
  6. Done: the workflow is published and active once setup is complete.

With the CLI

shell
curl -fLO https://usertasks.com/gallery/workday-worker-change-access-1.0.0.utpkg
usertasks packages inspect workday-worker-change-access-1.0.0.utpkg       # offline: checksum, hashes, signature
usertasks packages install workday-worker-change-access-1.0.0.utpkg --dry-run
usertasks packages install workday-worker-change-access-1.0.0.utpkg       # prompts for each requirement
usertasks packages install workday-worker-change-access-1.0.0.utpkg --keep-incomplete --yes   # in CI; finish with:
usertasks packages complete workday-worker-change-access -f values.yaml

Verify the download

File SHA-256
43b69d0ed7e9d68df142f33edde6b8f897d40cf5d0b96cb2ba9596a15930210a
Package checksum (what is signed)
sha256:4ac8f1a896ee1e87daf6c87079bc065c4348eea318d070b48d210adc8403b877
Signer
Unsigned preview build — compare the SHA-256 above

shasum -a 256 workday-worker-change-access-1.0.0.utpkg should print the file SHA-256. How gallery packages are signed.

Versions

Version 1.0.0

  1. v1.0.02026-10-28First release.

Installing a newer version upgrades in place: local credentials and requirement values are kept, and changes you made are flagged first. How packages work

More packages

Related

Browse the whole gallery