Employee Onboarding - Form Fields

Agree fully!

Great suggestion.  It goes without saying that this should be implemented for the Offboarding Module as well :)

The employee onboarding captures all data from the onboarding submission into text data. This makes functionality in other parts of FreshService not work correct.  For example

 

1. This text data does not flow into the mobile app because the mobile app only shows ticket description and ticket field data. It is impossible to work on the ticket.
2. You can’t use business rules on any of this text data or questions because business rules rely on fields.
3. You are unable modify any of the answers captured during the stakeholder submission process in the portal like a regular incident. Example, HR needs to change the start date, or Modify job title or name due to typo.  None of this can be edited from the support portal ticket view because it’s all text data.  Only form fields can be granted permission to be modified in the service portal.

 

The onboarding module needs to have it’s own form fields in field manager.   By moving the questions created in employee onboarding setup to Field Manager it fixes all of the above 3 problems.

1. The mobile app will show everything correctly
2. business rules will work
3. you can modify the form field to allow requesters to view/modify as needed.  

 

Brilliant suggestion to add the Onboarding Form into Field Manager to allow Admins to better control what information Requesters and Approvers see after submission of the Onboarding Form and also for Offboarding Form.

+1 This is gold, hope this is considered! We could really benefit from the mobile view and business rules.

If I may add... a MAJOR addition if this data is in fields, we can also use them in analytics reports. I currently have a report for onboarded users but can only view the subject and crated date of the ticket in the table view; not able to filter by anything else like hiring department from the fields on the ticket. 

After thinking about this some more, how does the community create New Hires as requestors or is this a concern for others? 

I have a workflow “Create Requestor from Onboarding”, created long ago and forgot about it. This calls the requestor object to create the newly hired onboarded user from the onboarding module as a requestor with the fields from onboarding to the requestors profile (address, email, phone, reporting manager, office location, etc.). If these fields change all this will break. Could this also be a feature request baked into the onboarding module?

​@Kamakshi V  Do you know if this is on the roadmap or considered by the product team yet? 

After thinking about this some more, how does the community create New Hires as requestors or is this a concern for others? 

I have a workflow “Create Requestor from Onboarding”, created long ago and forgot about it. This calls the requestor object to create the newly hired onboarded user from the onboarding module as a requestor with the fields from onboarding to the requestors profile (address, email, phone, reporting manager, office location, etc.). If these fields change all this will break. Could this also be a feature request baked into the onboarding module?

 

 

​@Kamakshi V  Do you know if this is on the roadmap or considered by the product team yet? 

As we use Google Workspace our onboarding workflow simply Creates a new user in Google Workspace Admin using the Orchestration app. We then use the G Suite users sync app to sync that user back to FS.

I would assume the AzureAD / Powershell orchestrators would provide a similar output for 365 environments.

After thinking about this some more, how does the community create New Hires as requestors or is this a concern for others? 

I have a workflow “Create Requestor from Onboarding”, created long ago and forgot about it. This calls the requestor object to create the newly hired onboarded user from the onboarding module as a requestor with the fields from onboarding to the requestors profile (address, email, phone, reporting manager, office location, etc.). If these fields change all this will break. Could this also be a feature request baked into the onboarding module?

 

 

​@Kamakshi V  Do you know if this is on the roadmap or considered by the product team yet? 

Hey ​@BryceK !!

Let me check with the Product team and come back!

And the (hopefully) upcoming Employee Transfer module!

After thinking about this some more, how does the community create New Hires as requestors or is this a concern for others? 

I have a workflow “Create Requestor from Onboarding”, created long ago and forgot about it. This calls the requestor object to create the newly hired onboarded user from the onboarding module as a requestor with the fields from onboarding to the requestors profile (address, email, phone, reporting manager, office location, etc.). If these fields change all this will break. Could this also be a feature request baked into the onboarding module?

 

 

​@Kamakshi V  Do you know if this is on the roadmap or considered by the product team yet? 

As we use Google Workspace our onboarding workflow simply Creates a new user in Google Workspace Admin using the Orchestration app. We then use the G Suite users sync app to sync that user back to FS.

I would assume the AzureAD / Powershell orchestrators would provide a similar output for 365 environments.

Similar here, workflow triggers creation in Local AD.  Requester sync is from local AD sync using FS Probe.

ping ​@Jatin Rastogi ​@Tejas Chheda 

Hello Everyone,

First of a big thanks for highlighting the painpoints. This really helps us prioritize the most pressing issues!

Ability to use the the onboarding data in other places is something that we have in our roadmap. Unfortunately i do not have a concrete timeline as yet. However i will keep this thread updated as soon as we have some updates

Fantastic news!  Looking forward to these changes.

Hello ​@Tejas Chheda 

Any update on this topic. As we have some automations based on this, this is really impacting us not being able to update these fields.

Thank you

Also looking for an update.  Thank you!

Wondering when this will be rolled out?  

Employee onboarding forms are a crucial step to ensure all necessary details are collected accurately from the start. It also highlights the importance of secure access systems where employees can later manage their information. Many organizations use centralized portals like the LiteBlue login page, allowing employees to securely access payroll, personal details, and onboarding-related data in one place. This kind of integration really improves overall HR efficiency.

I agree with this suggestion. When onboarding information is stored as plain text instead of structured fields, it becomes harder to automate workflows, manage updates, and make data available across different tools. Many large employee self-service platforms rely on properly mapped fields for account management and employee services, which is why resources such as the LiteBlue USPS employee Login Portal are good examples of how centralized workforce systems benefit from organized and accessible employee data.

​@Kamakshi ​@Jatin Rastogi ​@Tejas Chheda 

Any news on this?