Guidance on App Development - offboarding process

[Matthew Udovich]

A colleague and I are being tasked with creating an offboarding process/app. We are both fairly new to SN, but have developed some forms and catalog requests, as well as we do have AES set up completed. We are looking to build out the offboarding in AES. 

My first question is in relation to tables, our data set will not be compete all at once, our HR team would submit a form to start the process and then other forms need to be assigned to managers or other people to gather the rest of the needed data. 

For the experienced developers out there, should this be all in one table, or should each form have its own table? If each has its own table, what is the best way to link/relate them so we can pull data from multiple form submittals to create the information inside the assigned tasks? Do all the tables just extend the Task table? Or does the table of the first form extend the Task table and then each subsequent form/table is extended from that original custom table?

Apologies if this is confusing, I appreciate the help.

[ahefaz1]

@Matthew Udovich ,

I would recommend to look at the servicenow Lifecycle event solution for Offboarding. This comes with the HRSD plugin and you should be able to install this on your PDI.

ServiceNow uses the lifecycle events to streamline the offboarding, onboarding and other processes, where a parent case is used to track the offboarding for the user and the different tasks are created with the base case as their parent. 

These tasks are assigned to different people and groups related to the person being offboarded.

It is a pretty comprehensive solution and I would suggest to get some insights from it.

Below are some of the HRSD plugins that help

Human Resources Scoped App: Core
Human Resources Scoped App: Employee Relations
Human Resources Scoped App: Integrations
HR Service Delivery Virtual Agent Conversations
Human Resources Scoped App: Workspace

Human Resources: Lifecycle Events

Please mark helpful if this helped.

Thanks,

[Kristen Ankeny]

I would step back from "forms" and who needs to fill out what - you can control all that with the right roles/views. When architecting the table model you need to look at what they are trying to capture and how they are related and what the process requires. You can look at how catalog works as an example: I have a request table, a requested item table, and then catalog tasks. I have a single request that represents everything I asked for at one time. Then a requested item for each item that I need. And then I can have multiple catalog tasks to be able to break up the fulfillment across multiple groups. But in incident, it's slightly different - I have a main incident that captures the reported incident. I could have a process that just reassigns that incident to different groups through its lifecycle; or I could have incident tasks to allow multiple groups to tackle the incident at one time. In essence, you are trying to understand what the process is and how they need to be able to view and report on information. If I have a record that might be needed more than once in the process, the question I would ask is "do they need a discreet capture of each time this record is invoked or do they just want to see the most recent iteration of that record?" If discreet, I might create a related record that has a one to many relationship to the parent record; if just most recent either a separate table or fields on the parent record, depending on if they are representing truly different things or not. There are a lot of considerations to a good model, so unfortunately I can't say exactly what your model should be. But hopefully the above helps provide some direction.