Now Available: Enhancement to Automations

Document created by Brendan Cooper Administrator on Feb 22, 2018Last modified by Yum Darling on May 15, 2018
Version 7Show Document
  • View in full screen mode

Samanage is excited to announce enhancements to the automation feature. Automations allow you to build triggers based on conditions in order to take actions automatically cutting down on manual work.

 

Not only are we enhancing the different conditions you can make and actions you can take, we are introducing an additional trigger.

 

Below we will walk you through the new functionality:

 

New Comment Trigger

 

This trigger will allow you to take actions when a new comment is made on incidents and service requests.

 

First things, first:

 

Selecting a trigger is the starting point of your automation rule. Previously, we only supported the trigger “Create” for when a new incident or service request first hits the system. Now, you have the option to pick “New Comment” for when a new comment is made on an incident or service request. Please note that all automations rules created prior to this release will automatically be updated to the “Create” trigger.

 

 

We will be adding more triggers so stay tuned for updates on the Community!

 

 

How to set a comment trigger:

 

Under the Automations section in the setup menu, find the Trigger dropdown and pick “Comment added”

 

 

Note that depending on the trigger you choose, different options for conditions and actions will be available.

 

 

 

New conditions available for the “New Comment Trigger”:

 

Conditions Available for New Comment Trigger

Condition

When to use

Commenter Parameters:


User, Email Domain, Group, Role

Allows you to choose specific commenter parameters per your needs:

  • User: Allows you to choose a specific user(s)
  • Email Domain: This allows you to use the email domain of the commenter as a condition (ex. All emails coming from the domain @samanage.uk will go to our UK Service Desk)
  • Group: This allows you to use a Group that a commenter belongs to
  • Role: This allows you to use the commenters Samanage Role to set conditions

Note: If you do not select a specific Commenter parameter, the conditions will apply to all users.

Visibility

Allows you to build specific rules for Private vs. Public comments.


Note: If you do not select a specific Visibility parameter, the condition will apply to all comments.

Keyword

Allows you to use a specific keyword as a condition

Object Commented On

Allows you to choose specific attributes as a condition for the object that was commented on, including:

  • Category
  • Department
  • Origin
  • Priority
  • Site
  • State
  • Subcategory

Actions Available for New Comment Trigger

Action

What it does

Add Tag

Adds a tag to the incident that was commented on

Change Category/Subcategory to

Allows you to change the Category/Subcategory to the incident that was commented on

Change Department to

Allows you to change the Department to the incident that was commented on

Change Due Date to

Allows you to change the Due Date the incident that was commented on

Change Priority to

Allows you to change the Priority to the incident that was commented on

Change Site to

Allows you to change the Site to the incident that was commented on

Change State to

Allows you to change the State to the incident that was commented on

Notify By Email

Sends email notifications to the user/group that is selected

Reassign to

Reassigns the ticket



 

New Comment Use Case:

 

Requester Response to Ticket

The experience that this enhancement will boost is notifying your technicians when a comment has been made on an incident.

 

Think about a requester submitting a ticket but not giving you all the information you need in order to resolve the issue. You asked the requester for more information by replying in a comment and change the Incident State to “Awaiting Input”. In order to better notify you when they commented back, we build the automation rule with the:

 

Conditions:

  • Object Commented On > State: Awaiting Input
  • Visibility: Public
  • Commenter->Role: Requester

 

Actions:

  • Change State To: Assigned

 

Note: We have an added benefit with this automation rule! It is best practice to not have SLA rules apply when in a state like “Awaiting Input”. This led to a problem in the past, as a requester could have given the input, but the technician may not have seen that they got a response. This means that during that “lag” time the SLA rules are not running. Now you can stay true to your SLA rules, supporting the commitments you have made to the business.

 

 

Altering a Group - #criticalsupport

 

Technicians will run into situations where they need additional support on a certain incident.  With this new functionality you will be able use Keywords in a comment to alert a group of individuals to help assist in resolving the issue, or perhaps escalating the ticket.

 

For example, you may have a ticket that looks like it could lead to a critical impact to the organization and you want to notify the Critical Support Group. We built an automations rule with the:

 

Conditions:

  • Keyword: #criticalsupport
  • Private comments only

 

Action:

  • Notify by Email: Critical Support Group

 

Now a technician simply has to type #criticalsupport in a private comment and those in the Critical Support Group will be notified via email.

 

 

Resolving a Ticket Via a Comment

 

Let's take these automation rules to the next level, shall we? How would you like to resolve a ticket directly from a comment. To do so, use a similar technique as the above.  

 

Condition:

Keyword: #resolved

Visibility: Private

 

Action:

Change State to: Resolved

 

 

New Conditions/Actions for Incidents and Service Requests:

 

We have also added additional Conditions and Actions to the trigger “Create” for Incidents/Service Request

 

Conditions Available for Created Incidents/Service Requests

Condition

When to use

Requester Parameters:


User, Email Domain, Group, Role

Allows you to choose specific requester parameters per your needs:

  • User: Allows you to choose a specific user(s)
  • Email Domain: This allows you to use the email domain of the requester as a condition (ex. All emails coming from the domain @samanage.uk will go to our UK Service Desk)
  • Group: This allows you to use a Group that a requester belongs to
  • Role: This allows you to use the requester Samanage Role to set conditions

Note: If you do not select a specific Request parameter, the conditions will apply to all requesters

Origin

Allows you to set rules based upon the Origin of the ticket: Email vs. Portal vs. Manual Entry


Note:  If you do not select a specific Origin parameter, the condition will apply to all incidents/service requests.

Type

Allows you to build specific rules for Incidents vs. Service Catalog.


Note: If you do not select a specific Type parameter, the condition will apply to all incidents/service requests.

Additional Custom Fields

We now support User and Checkbox custom fields as a condition

State

Allows you to use the State as a condition

Actions Available for Created Incidents/Service Requests

Action

What it does

Change Category/Subcategory to

Allows you to change the Category/Subcategory of the incident/service request

Change Department to

Allows you to change the Department of the incident/service request

Change Due Date to

Allows you to change the Due Date of the incident/service request

Change Site to

Allows you to change the SIte of the incident/service request

Change State to

Allows you to change the State of the incident/service request

 

 

 

New Object Created Use Cases:

 

Routing by Email Domain

 

Say you have multiple business units that all have separate email domains, or you would like your vendors or consultants to use your Service Desk. Now you can start routing tickets based upon their email domain; ensuring that tickets are getting to the correct team more quickly.

 

For our example, we just bought a company call Spamanage (clever, right?), and while we are migrating the users into our systems, we still want them to be supported by their local teams. To set this up we built an automations rule with the:

 

Condition:

  • Requester > Email Domain: spamanage.com

 

Action:

  • Reassign to: Legacy Spamanage IT Support group

 

 

Routing and Categorizing by Keyword

 

Previously, you were able to route tickets based upon keyword, but there was no way to automate setting the category and subcategory. Now we can!

 

Say you want to route SAP related tickets to the SAP Support group, but also want to set this to the SAP subcategory. We built the automation rule:

 

Conditions:

  • Keyword: SAP

 

Actions:

  • Change Category/Subcategory to: Application Support/SAP
  • Assign to: SAP Support Group

 

 

As we continue to improve Samanage, we appreciate your feedback. Let us know what you think about this enhancement!

 

Your Samanage Team

7 people found this helpful

Attachments

    Outcomes