Presenter consoleSetupIntegration checkHelp center source

Clinician Onboarding ticket forms

Two forms, 22 fields. Everything below is what this Worker writes, so the spec and the integration are the same thing.

Use two forms rather than one. A parent request and a departmental task answer different questions, and a single form with everything on it makes both look wrong. Both forms are agent facing: these tickets are created by the integration, not filled in by a person, so nothing here needs to be visible to end users.

Drop-downs write tags, not labels. The tag beside each option is what the API sends, so those tags are part of the contract. Create the options with exactly these tags and the integration check will verify them for you.

Form 1: Clinician Onboarding the parent request, one per hire

System fields to keep: Requester (the clinician), Assignee and Group (HR), Type (Task), Priority (High), Subject, Description, Tags. Then:

FieldTypeWhy it is thereMapped id
Onboarding record required
record_type
Drop-downSeparates the one parent request from its task tickets in every view, and is what triggers branch on.
Parent requestonboarding_parentDepartmental taskonboarding_task
not mapped
Person number required
person_number
TextThe Oracle HCM key. Makes the write-back unambiguous and lets you find every ticket for one hire.
e.g. FMC-208471
not mapped
Clinician
clinician_name
TextThe requester already carries this, but a plain field keeps it in views and exports.
e.g. Dr. Emily Carter
not mapped
Job title
job_title
TextDrives which task set applies in a real build. Text, because HCM owns the vocabulary.
e.g. Physician
not mapped
Department
department
Drop-downReporting and routing by service line.
Emergency Medicinedept_emergency_medicineInternal Medicinedept_internal_medicineSurgerydept_surgeryRadiologydept_radiologyPediatricsdept_pediatrics
not mapped
Location
location
Drop-downBadge, parking and workspace work is site specific.
Florida Medical Centerloc_fmc_mainNorth Campusloc_fmc_northOutpatient Centerloc_fmc_outpatient
not mapped
Hiring manager
manager
TextWho gets the readiness notice before the start date.
e.g. Dr. James Wilson
not mapped
Start date
start_date
DateThe deadline every task is measured against, and the basis for any SLA or reminder.
e.g. 2026-09-14
not mapped
Employment type
employment_type
Drop-downLocum and PRN hires skip parts of the task set in a real build.
Full-timeemp_full_timePart-timeemp_part_timeLocum tenensemp_locumPRNemp_prn
not mapped
Source system
source_system
Drop-downProves the record came from HCM rather than a person, which is the point of step 1.
Oracle HCM Integrationsrc_oracle_hcmManual entrysrc_manual
not mapped
Clinician type
clinician_type
Drop-downDecides which credentials must be verified before clinical access is released.
MD or DOclin_md_doNurse practitionerclin_npPhysician assistantclin_paRegistered nurseclin_rn
not mapped
License state
license_state
TextPrimary source verification is per state.
e.g. FL
not mapped
License number
license_number
TextWhat Credentialing verifies against the state board.
e.g. ME-148902
not mapped
NPI
npi
TextNeeded for EHR and e-prescribing provisioning.
e.g. 1740283915
not mapped
Pre-start readiness
readiness
Drop-downThe one field a manager or exec reads. Written by automation, never by hand.
Not Readyready_not_readyReady for Startready_for_startCleared for startready_cleared
not mapped
Credential verification
credential_status
Drop-downThe gate itself. This is the field that releases the clinical access chain.
Pendingcred_pendingIn reviewcred_in_reviewApprovedcred_approvedRejectedcred_rejected
not mapped
Tasks complete
tasks_progress
TextProgress at a glance in a view, without opening the sidebar app.
e.g. 8 of 16
not mapped
HCM onboarding status
hcm_status
Drop-downMirrors what was written back to Oracle HCM, so the two systems can be reconciled from either side.
Not startedhcm_not_startedIn progresshcm_in_progressCompletehcm_complete
not mapped

Form 2: Clinician Onboarding Task the departmental tickets, sixteen per hire

Same person fields, so any single task ticket is readable without opening the parent, plus the three that describe the dependency:

FieldTypeWhy it is thereMapped id
Onboarding record required
record_type
Drop-downSeparates the one parent request from its task tickets in every view, and is what triggers branch on.
Parent requestonboarding_parentDepartmental taskonboarding_task
not mapped
Person number required
person_number
TextThe Oracle HCM key. Makes the write-back unambiguous and lets you find every ticket for one hire.
e.g. FMC-208471
not mapped
Clinician
clinician_name
TextThe requester already carries this, but a plain field keeps it in views and exports.
e.g. Dr. Emily Carter
not mapped
Job title
job_title
TextDrives which task set applies in a real build. Text, because HCM owns the vocabulary.
e.g. Physician
not mapped
Department
department
Drop-downReporting and routing by service line.
Emergency Medicinedept_emergency_medicineInternal Medicinedept_internal_medicineSurgerydept_surgeryRadiologydept_radiologyPediatricsdept_pediatrics
not mapped
Location
location
Drop-downBadge, parking and workspace work is site specific.
Florida Medical Centerloc_fmc_mainNorth Campusloc_fmc_northOutpatient Centerloc_fmc_outpatient
not mapped
Hiring manager
manager
TextWho gets the readiness notice before the start date.
e.g. Dr. James Wilson
not mapped
Start date
start_date
DateThe deadline every task is measured against, and the basis for any SLA or reminder.
e.g. 2026-09-14
not mapped
Employment type
employment_type
Drop-downLocum and PRN hires skip parts of the task set in a real build.
Full-timeemp_full_timePart-timeemp_part_timeLocum tenensemp_locumPRNemp_prn
not mapped
Source system
source_system
Drop-downProves the record came from HCM rather than a person, which is the point of step 1.
Oracle HCM Integrationsrc_oracle_hcmManual entrysrc_manual
not mapped
Clinician type
clinician_type
Drop-downDecides which credentials must be verified before clinical access is released.
MD or DOclin_md_doNurse practitionerclin_npPhysician assistantclin_paRegistered nurseclin_rn
not mapped
License state
license_state
TextPrimary source verification is per state.
e.g. FL
not mapped
License number
license_number
TextWhat Credentialing verifies against the state board.
e.g. ME-148902
not mapped
NPI
npi
TextNeeded for EHR and e-prescribing provisioning.
e.g. 1740283915
not mapped
Task category
task_category
Drop-downGroups the sixteen tasks into the five blocks the demo narrates, and is the basis for per-team views.
HRtask_hrITtask_itClinical systemstask_clinicalFacilitiestask_facilitiesCompliancetask_compliance
not mapped
Depends on
depends_on
Multi-lineWhat had to finish before this ticket could exist. The audit trail for the whole mechanism.
e.g. Create network and email accounts, Verify required licenses and certifications
not mapped
Released by
released_by
TextWhy this ticket appeared when it did. The one field that makes deferred creation visible on the ticket itself.
e.g. Credential verification approved
not mapped
Target completion
target_date
DatePer-task deadline, usually the start date or a few days before it.
e.g. 2026-09-14
not mapped

What to leave off

No free text status field, no "percent complete", no per-department checkbox set. Status lives in the ticket status and in the readiness field, and anything a person types by hand goes stale between the hire and the start date. Resist a field for the blocking reason as well: a blocked task has no ticket, so there is nothing to write it on. Released by is the field that carries that story, after the fact, on the ticket that did get created.

Setting it up

  1. Admin Center, Objects and rules, Tickets, Fields. Create the fields above. For a drop-down, add each option with the exact tag shown.
  2. Admin Center, Objects and rules, Tickets, Forms. Create Clinician Onboarding and Clinician Onboarding Task, drag the relevant fields onto each, and activate both.
  3. Copy each field id from the URL when you open the field, and paste them into the skeleton below. Set it as the ZENDESK_FIELD_MAP variable, Text type, one line.
  4. Copy each form id the same way into ZENDESK_FORM_ID and ZENDESK_TASK_FORM_ID.
  5. Re-run the integration check. It resolves every id, checks the type, and checks the option tags.

Skeleton, with anything already mapped filled in and the rest as zero. A zero, a missing key or a field whose type does not match is skipped on ticket create, so a partial map is safe.

ZENDESK_FIELD_MAP
{"record_type":0,"person_number":0,"clinician_name":0,"job_title":0,"department":0,"location":0,"manager":0,"start_date":0,"employment_type":0,"source_system":0,"clinician_type":0,"license_state":0,"license_number":0,"npi":0,"readiness":0,"credential_status":0,"tasks_progress":0,"hcm_status":0,"task_category":0,"depends_on":0,"released_by":0,"target_date":0}
Without any of this the demo still runs: the person appears in the ticket description, the routing tags are always applied, and the dependency mechanics are unaffected. The fields are what make the tickets look like a build rather than a script.