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!