Forrester's Total Economic Impact of Freshservice on IT Service Management Download Report

Start a new topic
Discussions Freshservice Roadmap
Implemented

Task-based Automations

Fixing certain Incidents, fulfilling certain Service Requests or carrying out certain Changes often require a fixed set of Tasks to be completed. While Task Management in Freshservice is great for breaking down work, it will be better with Automations.


Introducing Task-based Workflow Automations 


With Task-based Automations, Admins can configure rules


  • To create process workflows through Tasks for resolving Tickets and Problems or completing Changes and Releases
    • For e.g. Task-based Automations can be used to create a sequential workflow of Tasks that need to be completed for fulfilling a new laptop request
  • To route Tasks automatically based on configurable conditions
  • To notify Users on changes to the status of Tasks
  • To keep the parent Ticket/Problem/Change/Release fields updated based on Task events
  • And much more!


 



Task-based Automations will be available for Ticket, Problem, Change and Release Tasks.


26 people like this idea

Awesome.


Can tasks be automatically created when a ticket changes status (e.g. Pending to Approved)? From your screenshots, the events item only shows Task Status is changed rather than ticket.

Hi Leigh,


That's possible from the Ticket Automators. You should be able to configure a Ticket Automator rule that listens to status changes and creates a Task. Once done, you should be able configure subsequent workflows involving the Task in Task automator configuration.


-

Sundar

Hi Sundararajan,


That doesn't really sound practical. Unless I'm not understanding this correctly, I think you guys have missed a big opportunity with Task workflows. 


So for example, below you will find one of our workflows.


The workflows have several conditions + actions that the ticket could flow down. However ultimately the tasks at the very end are all the same. Due to limitations with FS, I've essentially had to duplicate 10 tasks for every single potential outcome (approximately 50 tasks in one workflow....). This is a nightmare to maintain as you can imagine.


image


Your suggestion above seems like we still create the tasks in the ticket workflow, but then maintain these in the task workflow? Why bother?

Why wouldn't you handle the task creation in the task workflow as well? Ideally you should still be able to reference the ticket table as an Event. As an example:

  • Event: Ticket is updated
  • Condition: If Ticket status changes to Open and Service Item = New Hire
  • Action: Create Task 1, Task 2, etc

Hi Leigh,


Thank you for detailing things out. A couple of points -

1. In Task automators - you will be able to listen to Task events, but should be able to reference the parent Ticket record for conditions (checking for approval status etc.) But, looking at the workflow that you have provided as a screenshot, it seems like you have a use-case to create Sub-tasks when something happens on the Ticket, and not on the Tasks themselves (which is a Ticket event), and Ticket automators seem like the right place for them.


2. You seem to have the same final action on all the branches of the Ticket automator rule. I understand how nightmarish this can be to maintain. Is there a way you can chop those actions from the branches and have a separate Ticket automator rule that abstracts the conditions from all of those branches? (Say, something like - Event: Ticket is status is changed. Condition: Ticket status is approved, Action: Create Subtasks)


That said, I do take your feedback on the need for the ability to listen to 'Any record event (be it Tasks, Tickets whatever)' from a rule. 

Let me know if I've misunderstood some of your inputs.


Thanks again for taking time to explain.


-

Sundar

Product @ Freshservice

Hi Sundar,


Thanks for the response. I've implemented your second solution but unfortunately FS doesn't work like this I'm told :( (just logged a ticket to support). I setup two workflows with the second workflow triggered off the status change, however it can't be done.


Message from support:


​Please be noted that an Action of the first workflow wouldn't be considered as an Event by the system due to which the second workflow wouldn't get triggered.

​

​This is a design restriction to avoid looping in the system.

​

So, the Status change should either be performed by any agent or the requester, or both the Workflow needs to be combined together into one.

Login or Signup to post a comment