Company Onboarding - How is your company set up to onboard?

Question

I'm currently reviewing and updating our employee onboarding process in Jira Service Management. Our existing onboarding form has become somewhat unwieldy and requires regular modifications as our requirements change.

Today, a submitted onboarding request automatically creates a parent service request and individual subtasks for the various IT teams involved in the onboarding process.

I'd be interested in hearing how other organizations manage onboarding in JSM. What does your workflow look like, and are there any tools, automations, or best practices you'd recommend to improve scalability and reduce ongoing maintenance?

Olha Yevdokymova_SaaSJet · Answer

Hi @Malee

Great tips above: branching the form and creating sub-tasks from one rule both keep things maintainable.

On the form side specifically, another approach you might consider is Smart Forms for Jira (developed by my team). It helps with the “unwieldy form that keeps changing” part:

* One form instead of many: conditional logic shows only the questions for the role, location or equipment that apply.
* One form across spaces: the same onboarding form can be reused in JSM, Jira Software and business spaces, so HR, IT and Facilities don’t keep separate copies — change it once and it updates everywhere.
* Map only what you route on (role, department, start date) to Jira fields for your sub-task automation. The rest stays in the form, so you don’t need dozens of custom fields.
* Auto-attach extra forms by work type — for example an IT equipment checklist on the IT sub-task.
* External sharing: send a pre-start form to the new hire by link, even before they have a Jira account.

A setup that scales well:

→ one onboarding form with conditional sections

→ automation creates sub-tasks based on the mapped answers

→ each team gets its own small form auto-attached to its sub-task

Here’s an example structure for HR onboarding if it’s useful as a reference. Happy to clarify if you’re exploring this setup.

Shaik Riyaz · Answer

Hi @Malee ,

We run employee onboarding in JSM using Journeys, not form-driven subtask automation. It's been much easier to maintain:

* One journey type as the template: All onboarding steps (HR documents, IT accounts, laptop/assets, facilities) live in one journey type under Space settings → Journeys. Each step is a work item in the journey.
* Conditions instead of automation branches: Use Actions (…) → Add condition on a step so it's only created when it applies. For example, "Assign office space" only for non-remote hires. You can add up to 5 conditions per step (AND logic). Conditions can only use values on the journey parent, so make sure your request form fills in fields like role, location and employee type.
* Adjust one hire without editing the template: Turn on Allow admins to customize each journey and set a timeout period. Admins can then edit or add conditions to a single journey's steps. Locked steps can't be changed.

Thanks!!

Rolf Eriksen -Eriksen Labs- · Answer

Hi Malee, two things tend to keep an onboarding setup manageable as it grows.

* Let one form branch instead of getting longer. JSM forms can show a section only when an earlier answer matches. The trigger must be a radio, checkbox or dropdown field, not a multi-select. The requester then sees only the questions for the role, location or equipment that apply:

https://support.atlassian.com/jira/kb/use-forms-to-set-conditional-fields-in-service-projects/

* Create the sub-tasks from those answers in one rule. After "Work item created" for the onboarding request type, use IF/ELSE blocks, or a Create lookup table action that maps an answer to a team, and create only the sub-tasks that are needed, each assigned to its team:

https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/

Adding a team then means changing one rule, not the form plus several rules.

Joseph's point about keeping the parent open until every sub-task is done is worth adding as well. If you share roughly how many teams and variants you have, people here can suggest a concrete layout.