Happy Monday, everyone. Every week we pick a topic and share our point of view along with a solution. This week, we’re trying something different. Instead of giving you answers, we want to give you the right questions — so you can reason through them, shape your own strategy, and land on a solution that actually fits your needs.
Here are ten design questions, organized around the themes that matter most when building HR onboarding automation in Atlassian Service Collection.
It all starts with a hiring event: an employee is hired in your HRIS, and a ticket is created in JSM with all their details. Hiring process seldom follows a straight line.
1. What if the hire date gets pushed out? Does the onboarding ticket sit idle with stale dates? Do all the downstream tasks such as laptop provisioning, badge creation, account setup automatically shift, or does someone have to manually update each one?
2. What if the employee rescinds the offer? Is there a clean way to cancel the onboarding ticket and all its subtasks in one move? Or do five different teams discover weeks later that they’re still prepping for someone who isn’t coming?
3. What if the employee doesn’t get onboarded, but months later is rehired? Does your automation recognize them as a returning employee and skip steps they’ve already completed e.g background check, tax forms, policy acknowledgments.
4. How far in advance of the start date should the onboarding ticket be created and should that lead time vary by role, department, or location? A software engineer in headquarters might need two weeks of lead time for equipment and access. A seasonal warehouse worker starting Monday might need two days.
5. What happens when multiple HRIS events fire in quick succession e.g a hire is entered, the department is corrected, then the manager changes? Does each event create a new ticket, update the existing one, or get ignored? If your integration isn’t idempotent, you could end up with duplicate tickets, conflicting data, or both.
6. Some onboarding tasks depend on others e.g you can’t set up email until the laptop is assigned, and you can’t assign a laptop until procurement approves it. How do you model those dependencies so tasks don’t land on someone’s queue before they’re actually actionable?
7. If onboarding spans fifteen tasks across five teams, does the new hire see one clean experience tracking their progress or do they see the internal chaos of subtasks, queues, and handoffs? The employee’s first impression of your company shouldn’t be a service desk ticket that was clearly designed for agents, not for them.
8. What employee details actually need to flow from the HRIS into JSM and where do you draw the line on PII? Push everything and you’ve got sensitive personal data sitting in a ticketing system that half the IT department can see. Push too little and agents are constantly swiveling back to the HRIS to look up basic information. Where’s the right balance for your organization?
9. When a task is delayed e.g the laptop hasn’t arrived, the badge isn’t ready, access hasn’t been provisioned. Does the employee find out proactively or do they discover it by showing up to a locked door?
There is no one right answer to the above questions. The right answer depends on your organization’s process, complexity, and experience. But if you can’t answer these questions clearly, you are leaving something left to be desired.
We’d love to hear how you’re thinking about these. We intentionally left the 10th question. Add your questions to the comment on what other design questions that need to be considered.
If any of these questions connected with you and you’re looking for help designing the right onboarding automation in JSM, pease give OnLink a try.
