Clinician onboarding demo setup

Check the integration first

Run the integration check. The Worker calls your sandbox and reports, check by check, whether authentication, the six groups, the group id map, the clinician end user, the sidebar app install and the Guide article are actually in place, with the fix for anything that is not. It also offers a live ticket test that creates a ticket, comments, solves and deletes it, which is the only way to prove write access end to end.

1. Worker variables

Worker › Settings › Variables and Secrets. All optional. Without them, tickets are simulated and every screen still works.

The type dropdown offers two choices, Text and Secret. There is no JSON type: the group map goes in as Text, on one line.

Values are trimmed, so a stray trailing space will not break anything. Anything left unset simply turns that behavior off: no Zendesk credentials means simulated tickets, no group map means tag based routing, no PIN means no PIN.

Optional KV: bind a namespace as STATE so demo state survives isolate recycling. Without it state lives in memory, which is fine for one presenter in one sitting.

2. Zendesk sandbox objects

1. Create groups: HR, IT, Clinical IT, Facilities, Credentialing, HR / Compliance.
2. Build the two ticket forms and their fields. The field spec lists all of them with types, option tags and a copy-ready field map.
3. Create an API token and put it in the Worker variables above.
4. Nothing to do for the clinician account. The hire provisions it: the Worker calls users/create_or_update with the name, role end user and verified true, sets their help center password, then requests every onboarding ticket as that user. Run the demo twice and the same user is reused.
5. Turn on Support › Settings › Security › Global › allow admins to set passwords, if you want the hire to set the clinician password for you. It is off by default, and without it that one step is manual.

3. Install the sidebar app

Upload fmc-onboarding-sidebar.zip at Admin Center › Apps and integrations › Zendesk Support apps › Upload private app. When it asks for settings, set Worker URL to:

https://oracle-hcm-sim.solutions-8f6.workers.dev

The app is a thin ZAF v2 host. Its UI and logic are served from this Worker at /app.js, so you can change the app without reuploading it to Zendesk.

4. Publish the help center article

Open the help center source. It gives you two pieces: a theme snippet for document_head.hbs that loads the status widget, and the article HTML for an article titled Your clinician onboarding journey.

The help center is end-user facing only. The status panel reads HelpCenter.user.email and calls /api/my-status, which returns an onboarding record only when the signed-in email matches CLINICIAN_EMAIL. Anyone else gets "no onboarding request is associated with this account", and an anonymous visitor gets a sign-in prompt. Internal task tickets are tagged internal with no requester, so they never appear in the clinician's request list.

5. Signing in as the clinician

For the help center half of the demo you need a browser signed in as the clinician, in a second profile or an incognito window. After the hire, use:

The hire sets the password on whichever clinician you pick, so only that one can sign in until you hire another. Plus addressing keeps them separate users in Zendesk while every message still arrives in the one inbox. It works with Gmail and most modern providers.

The hire sets this password on the user each run, so it is always current. If the password step is refused, the integration check says why, and setting it once by hand on that user has the same effect.

This page shows the password in the clear. It is a sandbox end user for a fictional clinician, but treat the Worker URL as internal, and set DEMO_PIN if it will be shared.

6. Run the demo

1. Open the presenter console on your screen, and the Zendesk agent view plus Oracle HCM on the shared screen.
2. Step 1: pick a clinician and hire them, from the console or from Oracle HCM. Five are available, with different roles, sites and task counts. One onboarding runs at a time.
3. Steps 2 to 4: eight task tickets appear across five groups. Eight are withheld, including the whole clinical access chain, because their dependencies are not met.
4. Step 5: approve credentialing. The EHR ticket is created at that moment, in front of the audience.
5. Step 6: readiness reads Not Ready with compliance training outstanding, then Ready for Start.
6. Steps 7 and 8: write back to Oracle HCM, solve the parent ticket.
7. Reset from the console header between runs.

API reference