Skip to main content

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!

Onboarding desperately needs a full rewrite. A typical onboarding process at our organisation includes about 50 tasks - these are now setup in difficult to maintain automation workflows.  Onboarding/offboarding needs the following improvements:

  1. Build onboarding kits with groups of tasks as well as groups of tickets - we don't want 50 tickets per new joiner - tasks are the way to go.  
  2. But, the automation workflow around tasks is very limited, you cannot even link task due dates to expressions in the workflow automator
  3. Handle onboarding dates in a logical way - there's no built-in link between the onboarding date and the ticket/tasks due dates - this is crazy!  Onboarding processes are driven by the onboarding date, not the date the onboarding request was created.
  4. There should be native functionality to have additional tickets/tasks trigger after the onboarding is over - there are dozens of followup tasks that occur after people join that need to be automatically tracked

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


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 


I opened another idea for moving onboarding questions to field manager. This will address the issue of Fields being modified for both the requester and agent.

Please help vote for this so it gets considered.

 

 


I created an idea for the dept share functionality which according to support is the only way to log enhancements or missing functionality in a trackable manner.  It needs significant upvotes before it will be considered.

I linked this thread to the idea.  Please help upvote so it can be considered and fixed

 

.


I know onboarding and offboarding are in their infancy with FreshService I would keep checking it out to see what updates they have added and don’t stop the suggestions it will give them a direction to move on.  I know just in the two months I have attempted to use it they have made many improvements.


Reply