Onboarding tickets can’t be shared via the “share tickets with department” interface.
Onboarding tickets form fields can’t be edited. Despite presenting a similar visual interface to Service Catalog Items, which _can_ be edited after submission.
Onboarding tickets can be shared with the new Sharing API, but they won’t show up in Employe Journeys.
Onboarding tickets submitted by other users do not show up for Business Agent users with Onboarding Supervisor (or general Admin level) permissions in Employee Journeys. Even though Business users licenses are marketed as a way to integrate HR and other business teams who might need insight into the onboarding process. These accounts can’t see all of the available Onboarding tickets in the Employee Journeys section. The tickets do show up in the tickets module, but look like every other ticket, which renders moot the whole point of the separate Employee Journeys section.
Onboarding tickets are limited to (3) stakeholders. Any stakeholders added after the first initiator make it such that the ticket cannot be edited until the succeeding stakeholder has “approved” any stakeholder specific information.
If your IT requisition team needs to make a change they are unable to do so, or are forced to request the ticket be resubmitted if they notice an error, which waste valuable time. There also is no way to override approvals or just auto-approve these steps.
Stakeholders who are assigned to a ticket don’t have the tickets they are designated as stakeholders for added to their Employee Onboarding view from the requester portal. How does this make sense? A one time chance to have input into a ticket is so disappointing.
Why would you not give a designated stakeholder access to the Onboarding ticket they’ve been designated to in the Employee Onboarding section of the requester portal?
At least the new ticket sharing API has finally made it possible to share an individual ticket, but it does not show up under the designated Onboarding sections of the UI. It’s only available directly at the ticket URL or in the general “Tickets” module view, making it no different that a regular Service Catalog Item, except that it’s harder to share for some reason.
Onboarding ticket also don’t let you pre-select an individual as stakeholder - stake holders are only selected at run time. So if specific account is always supposed to be a stakeholder there’s no way to ensure they are.
Onboarding tickets also don’t share the same GUI improvements that have been added to Service Catalog items, despite being based off the same visual interace (albeit an outdated one). One example is that dependent fields aren’t visually shown to be hierarchical with a└ symbol in Onboarding requests, even though these fields show up this way for Service Request Items. There are also other visual improvements to service catalog item field editing that for some reason haven’t made their way to identical onboarding fields.
It has been a genuine embarrassment for me trying to implement onboarding via the onboarding module in Freshservice
I have had to say “I don’t know why it was designed this way” so many times that it’s literally hurt my own credibility for suggesting it can be used as onboarding system.
The only saving grace of this platform is that I can replicate the functionality we need through REST API calls, Remote Scripts, Workflow Automator, and some external dashboards, but I really should not have to. But here I am designing a highly custom workflow because the Onboarding module is so limited and deficient.
It really is a huge disappointment, does anyone else have these same problems? Is it ever going to be improved on? It feels so half baked.
Onboarding tickets inherit deprecated Service Catalog Item interfaces, but are specially designed NOT to be included in the general tickets view. Make it make sense!
The Onboarding Module has single handedly killing my enthusiasm for Freshervice.
![Wizard of Creative Thinking (10) Badge](https://uploads-us-west-2.insided.com/freshworks-en/attachment/5983a247-38c2-465d-b9a5-94ff0bcb041b_thumb.png)
Encountering such frustrations with Freshservice's onboarding module can be incredibly disheartening. From limitations on editing tickets to the lack of visibility for stakeholders, it's understandable how these issues can impede workflow efficiency. While workarounds like using REST API calls and external dashboards help, they shouldn't be necessary. Here's hoping Freshservice takes user feedback seriously and works to improve the module's functionality and usability.
Can agree, i have stopped using on/offboarding modules a long time ago and work with service items/workflows etc instead. Those modules in my opinion were ‘added hastily’ while still in beta stage and then never grew into professionalism
Hi,
It feels that On- and Offboarding where only added for the feature list but the are almost unusable.
Number of Stakeholders is limited, the can not be predefined or set to a Agent Group.
The Item Kits implementation is a joke, it does not handle the bundles set in service items, the stakeholder can not select an entire Kit, multiple kits content is mixed in the selection, there is no way to handle dependencies (can not select Kit B if Kit A selected) aso.
The Create Tickets Option is to static, i want a filter to create a ticket only if a stakeholder provided some information in a custom field aso.
Many of these issues have been mentioned here a long time age (1 year) and nothing has improved.
Please this needs to be fixed asap
Reply
Sign in to the Community
Social Login
Login for Freshworks Employees Login with LinkedInEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.