INTRODUCTION

In every company, it is crucial to have effective, efficient communication, such as the ability to alert your team about new urgent issues, or let a customer know you’ve responded. Thanks to API integration and webhooks, Vivantio makes sending messages to applications such as Microsoft Teams from your department easy. If your organisation uses Slack instead, you can find a tutorial on sending out communication from Slack here.

This tutorial will show you how to configure this in Microsoft Teams and provides two examples of using notifications in the Vivantio platform. Please note that Microsoft Teams transitioned to a new webhook URL format to enhance security on January 11, 2021. If you've configured this integration prior to that date, there are new set-up instructions included at the end of this blog for Step 7.  

To connect Vivantio to Microsoft Teams, you’ll need:

1. Vivantio ITSM
2. Admin access to your Vivantio Instance
3. Permissions in MS Teams to create, update and remove connectors for the Team you wish to post to

CONFIGURATION IN MS TEAMS

Step 1:

Begin by logging into Microsoft Teams (MS Teams). You will then go to:

Your teams » Click on the channel within MS Teams you want to send notifications to » More options » Connectors

Step 2:

If it’s not already installed for the selected MS Teams group, add and install Incoming Webhook. Otherwise, configure Incoming Webhook.

Step 3:

Enter a name for your webhook (this will be the username associated with messages sent into MS Teams), upload a custom image if desired, and select Create.

Step 4:

Next, copy the URL that is created, circled in red below. This will later be used to set up the webhook in Vivantio.

CONFIGURATION IN VIVANTIO

Step 5:

Log into Vivantio, open the Admin Area. Navigate to:

Integration & API » Webhooks » Add Webhooks

Then select the ticket type you want the webhook to be available for.

Step 6:

Enter a name for your webhook.

Step 7:

Next, navigate to the Basic Details tab and enter the following information (please refer to the Update at the end of this blog if you configured this integration prior to January 11, 2021):

• Request URL: Paste here the URL produced when you configured the incoming webhook in MS Teams.
• HTTP Method: POST
• Response Content Type: text/html

Step 8:

This next step, filling out the parameters tab, is optional. Set up parameters for the webhook by selecting Add. These are either values the technician will be prompted to complete, or populated automatically from the ticket. In this example, we have created a multi-line text field for a technician to enter the message that they wish to send into MS Teams.

Step 9:

Now, fill out the Request Body tab.

For the Request Content Type field, select application/json. The Body Template will contain the information you wish to send in MS Teams notification, such as specific text, details from the ticket or a webhook parameter. Screenshots from the Request Body of two example webhooks are given below.

Example 1:

A notification message sent into Teams that utilizes the webhook Parameter we created in the previous step.

{"text": ""}

Example 2:

A notification sent into Teams that includes details from the ticket. In this case, we use fields from the ticket. The “\n\n” signifies a line break. Note that Steps 1 through 8 were followed to create another webhook “Teams – High Priority Ticket.” Once the Request Body is filled in, click save.

{"Title": "High Priority Ticket Logged",
"text": "Ticket Details: \n\n ID: {{ticket.displayid}} \n\n Subject: {{ticket.title}}
\n\n Caller Name: {{ticket.callername}}"}

Step 10:

The last step before we can use our new webhook is to configure its roles. By default, there will be no roles assigned to the webhook. To update the roles, select the webhook and click Roles. Drag the roles you want the webhook available for into Current Roles.

Now let’s put the webhooks we set up into action!

You can use your webhook to send ad hoc notifications into MS Teams directly from a ticket window or you can execute your webhook through Trigger Rules. Two examples are given below:

Example 3:

An ad hoc message sent into MS Teams from a Vivantio ticket window

Actions » MS Teams Notification

The technician is prompted to fill in the “Notification to Teams” parameter we set up in the webhook. Recall that this webhook was configured so that the text entered here will be sent into MS Teams.

Press OK and voila! This message is sent into MS Teams.

Example 4:

Sending a notification to an IT team’s channel in MS Teams any time a high priority ticket is logged.

In this case, you can set up a trigger rule to automatically execute the webhook when a high priority ticket is logged. Go to:

Admin area » System Areas » Select the ticket type you created the Webhook for
» Business Rules » Trigger Rules

To add a trigger rule, click Add, then:

• Enter a Rule Name and select when the condition is to be executed, either when the ticket first meets the condition (for example, if you just want people to know the ticket was created) or when the matching ticket is updated (if you want everyone to see all updates to the ticket).

• Enter the condition(s) for the trigger. In this example, the trigger rule condition is for tickets with the priority name equal to “high.”

For the trigger rule “Actions” select

Webhooks » Webhook you want to fire; in this case, we chose

Teams – High Priority Ticket » Save

Once the trigger rule is set up, the “Teams – High Priority Ticket Webhook” will automatically send a notification with ticket details into MS Teams any time a “High Priority” ticket is logged.

CONCLUSION

There you have it! Now you can easily communicate to any team in MS Teams directly from Vivantio.

Update (as of January 11, 2021):

This step is for anyone who configured this integration prior to January 11, 2021. On this date, Microsoft Teams transitioned to a new webhook URL format to enhance security. You will need to update your webhook URL from within Microsoft Teams and copy the new URL into the webhook within Vivantio (Step 7).

To update your webhook URL within Teams, navigate to your webhook:

Your Teams >> Click on the channel your webhook is configured on >> More options >> Connectors

Select Configured. Find your webhook and select Manage.

If your webhook URL needs to be updated, an "Update URL" button will appear to the right of the URL. Select Update URL.

Once your URL is updated, it will say "URL is up-to-date" below the URL. Copy the new URL into your webhook within Vivantio (Step 7).

Azure DevOps–formerly named Visual Studio Team Foundation Server (TFS)–is a Microsoft product that allows developers to plan work, collaborate on code development and build and deploy applications. If your development teams are using Azure DevOps, integrating it with your service desk software can provide the following benefits:

• Create bugs directly from Incidents or Tickets
• Create Product Backlog Items from Service Requests or Change Requests

Vivantio includes an out-of-the-box, two-way integration with Azure DevOps, making it simple to have open communication and visibility between your support and development teams.

Our Azure DevOps integration helps you streamline your processes and keep everyone informed of what is going on, regardless of which tool they work in day-to-day, so there's no need for your developers to log into Vivantio, and no more phone calls to the development team to check on the status of bugs!

This tutorial will show you how to configure the integration and provides an example of creating a Work Item in Azure DevOps directly from Vivantio.

To connect Vivantio to Azure DevOps, you’ll need:

1. Vivantio ITSM
2. Admin access to your Vivantio Instance
3. Credentials to a user account for Vivantio in Azure DevOps
   

CONFIGURATION IN VIVANTIO

Step 1:

Log into Vivantio, open the Admin Area. Navigate to:

Integration & API >> TFS

Fill in your Azure DevOps login credentials:

• Version: Azure DevOps
• Organization Name: Enter your organization name. This will be used in your API URL, for example: https://dev.azure.com/OrganizationName/
• Username: The username for the Vivantio user account in Azure DevOps
• Password: The Personal Access Token for the Vivantio user account in Azure DevOps. For details on creating a Personal Access Token, see the Microsoft Documentation here.

The bottom of the screen will update to show a couple of different URLs: the Work Item Alert URL and the Service Hook URL. You will use the Service Hook URL to set up Azure DevOps to send information back into Vivantio.

Step 2:

Select IP Range in the top left corner of the screen and configure the IP Range for Vivantio to accept requests from.

Step 3:

Configure your ticket to Work Item Mapping settings. This allows you to control which types of Vivantio Tickets can be mapped to which types of Azure DevOps Work Items so that the correct type of information can be transferred to the correct type of records. Any number of necessary ticket-to-work item mappings can be configured.

Navigate to the Ticket to Work Item Mapping tab and select Add.

On the Basic Details tab, give the mapping a name and fill in the following information:

• Project Collection: The Project in Azure DevOps (If you’re using the hosted version of Azure DevOps, there will normally only be one option available here)
• Project: The Project in Azure DevOps
• Work Item Type: The Work Item Type in Azure DevOps
• Ticket Type: The type of ticket within Vivantio that you want to create the Work Item from

Step 4:

Navigate to the Sync Options tab. Here you can configure the settings relating to the sync of data from Vivantio to Azure DevOps. (Note that this option does not force Azure DevOps to update Vivantio–that is configured within Azure DevOps itself). You have the option to fill in the following fields:

• Link Work Item to Ticket: Checking this box will create a link to the Vivantio ticket from within the Azure DevOps ticket
• Action Sync: Selecting “All” or “Non Private” will automatically sync all (or only non-private) actions made in Vivantio to the “Discussion” section within the Work Item in Azure DevOps
• Attachment Sync: Selecting “All” or “Non Private” will automatically sync all (or only non-private) attachments added in the Vivantio ticket to the “Attachments” section within the Work Item in Azure DevOps

Step 5:

Select the Field Mappings tab and configure any additional field mappings. As standard, Vivantio will populate the Work Item Title and Description. If you want to add additional mappings, e.g., for custom fields, you can do so here. You can also choose to override the default mappings for Title and Description.

In the example below, we chose to map several custom fields from Vivantio to Azure DevOps.

After choosing the appropriate options, hit Save, and you’re ready to start creating Azure DevOps Work Items directly from Vivantio.

CREATING A NEW WORK ITEM FROM VIVANTIO

When viewing a Ticket in Vivantio, under the Actions menu item, you’ll see the option to “Create New TSF Work Item.”

Selecting Create New TFS Work Item will open a pop-up window where you can select the Work Item Type. Any mappings created for the ticket type, using steps 3 through 5, will appear as options.Selecting OK will cause a “TFS” Form to appear in the Vivantio Ticket Window and a Work Item to be created in Azure DevOps.

The TFS form provides a direct link to the Work Item in Azure DevOps and provides the technician with the options to unlink the Vivantio ticket from the DevOps Work Item and to send ad-hoc comments and attachments to DevOps, which can be useful if you didn’t choose to automatically sync actions.

Clicking on the link to the Work Item in DevOps, we can see that the Work Item was created and the mapped fields were passed from the Vivantio Ticket to the Work Item.

CONFIGURATION IN AZURE DEVOPS

Getting Information Back From Azure DevOps

Configurations can be made in Azure DevOps to automatically send information from DevOps into Vivantio. This is done using the Service Hook that was create in Step 1.

Step 6:

To configure the Service Hook in Azure DevOps, navigate to Service Hooks within Project Settings in Azure DevOps (Microsoft’s documentation on Service Hooks can be found here). On the first page of the Create Service Hook wizard, you’ll choose the Webhooks option and select Next:

On the next page of the wizard, you’ll choose the type of event the Service Hook triggers on. Vivantio currently supports “Work Item Commented On” and “Work Item Updated.” Enter any filters you want for the area or work item type.

Select and configure the action to perform with the service hook. Under “URL,” paste your service hook from Step 1. Scroll to the bottom of the page and select “[Latest]” for Resource Version.

Now when we comment on Work Items in Azure DevOps...

...the comment is automatically added to the linked Ticket’s history in Vivantio:

Additional configurations can be made in Azure DevOps using Webhooks to automatically update fields in Vivantio based on updates in Azure DevOps.

If you’re using Vivantio and Azure DevOps and you don’t have them integrated yet, give it a try and see how it helps improve communications between your service desk and your development team.

WHAT ARE OPERATIONAL LEVEL AGREEMENTS?

In order to provide excellent customer service, you need to meet your service level agreements (SLAs): the agreements you have with your customers about the level of service you’ll provide. But how do you make sure you’re doing that? And if you’re not doing it, how do you understand why? The first step is making sure you hit your internal goals: your operational level agreements (OLAs).

Whereas SLAs are focused on the customer, OLAs are in place to describe the level of service your internal teams can expect from each other. These might include relationships between your front line service desk and the teams who support them: network support, operations management, application management, desktop engineers, etc..

They can–and should!–be used as a key metric in service management because they allow teams to understand where bottlenecks are, and why they’re not hitting those all-important SLAs. OLAs should also be transparent so that everyone knows what their own targets are, and the impact it has on the rest of the business.

However, sometimes service teams bite off more they can chew when attempting to measure SLAs and ultimately fail to meet them. Instead of setting goals for the sake of having them, start small by clarifying or setting up OLAs within your ITSM software tool. From there, you can begin building out SLAs.

Here’s how you can use task management in Vivantio to ensure your OLAs are being met.

TASK MANAGEMENT IN VIVANTIO

Task management in Vivantio can help companies meet OLAs and, in turn, meet target SLAs. Task management can be enabled in all ticket types in the Vivantio service management platform.

In Vivantio Pro, you can assign tasks to licensed technicians. Vivantio ITSM goes a step further and allows you to assign tasks to both licensed technicians and non-licensed end-users.

With task management enabled, technicians can create tasks for the different work required to complete the ticket. The list of tasks can be viewed easily from the ticket. Tasks have the same core capabilities as tickets, including their own set of configurations (categories, status, etc.) and of course a full history of the work done.

There are three ways that tasks are created in Vivantio: Ad hoc as needed, via trigger rules, and through Vivantio’s workflows. Regardless of the way tasks are created, you can easily view them from the ticket to track progress. Here are examples of creating a task using each way.

AD HOC TASK CREATION

Within Vivantio, users can create ad-hoc tickets as needed in order to request internal or external help to meet an OLA. Perhaps a technician is working on a P4 support request that came in with a corresponding SLA of 16 hours. While working on the request, they discover they’re not trained in a specific area of the required work and will need to ask their colleague for help.

To do this, they can manually assign out an ad-hoc task from within the ticket to their colleague – or if they don’t know who specifically to ask, an assignment group – describing what they need help with.

At this time, four hours have already passed on the SLA and only 12 hours remain. When assigning out the task, the technician gives the task an appropriate OLA to ensure that their colleague knows when they need to have the work completed in order to meet the ticket’s SLA.

This is a simple way to get started with OLAs. You might wonder why you don’t just re-assign the ticket, but there’s a few advantages in using task management. First up, you get to track each different piece of work separately; one ticket might need work to be completed by four different teams.

Vivantio will let you track the time each team/user owned the ticket, but it’s a lot easier to understand the timeline of a ticket when you’re using task management. Second, and we’ll talk more about the importance of this in a later blog, you improve the customer experience by ensuring the customer has a single named point of contact for their ticket so they don’t end up feeling like the buck is being passed.

Third, you make it very clear to other teams exactly what they do and don’t need to do so there’s no digging through the ticket history to find out their role in resolving this issue.

TASK CREATION VIA TRIGGER RULES

You can automate task creation within Vivantio using trigger rules. For example, when a request is logged reporting that a computer is lost or stolen, there are tasks that always need to be completed by both the IT team and the security team. Due to compliance reasons, it is required that this kind of request needs to be closed out within an eight-hour SLA.

Trigger rules can be created to automatically assign out the required tasks to the IT team and security team any time a lost or stolen computer request is logged. The tasks can have their own associated OLAs so that the teams know how long they have to complete the work in order to meet the request’s SLA.

The below screenshot shows two tasks that were automatically created via trigger rule due to the type of ticket that was logged.

Clicking into one of the tasks, we can see the SLA for the task, providing the target time to complete the work by.

This is a simple way to get your team started using tasks for repetitive work requests. Sometimes though, this isn’t quite enough. You need to ensure tasks are completed in a certain order, or tasks are only worked on after approval has been given. If that’s the case, then you need workflows.

WORKFLOWS

Automated workflows within Vivantio can also help you and your team manage your OLAs. For instance, say a customer of a software company submits a support request, which requires a specific process involving multiple people to complete. The request falls into a P2 priority request with a close SLA of 40 hours on a 9-to-5 working time plan, or five business days from the customer’s view.

Based on the category of the request, four different support teams will need to work on the request in a sequential order. In Vivantio, a specific workflow which automates the assignment of the process tasks is automatically kicked off using Vivantio’s trigger business rules.

Tasks are automatically assigned out to each team when it is their time to complete their portion of the work. In order to meet the SLA agreed upon with the customer, the total time in the SLA is broken down into OLAs, or smaller chunks of time which are allocated to each team.

There are several tasks that need to be completed by different teams and technicians during the workflow. In order to make sure to meet the target SLA, you can use operational level agreements for each task that is assigned out in the workflow.

This allows each person who is assigned a task to be aware of how much time they have in order to complete the task. The target OLAs for each task are set up to leave time for the transition between tasks and to complete the tasks themselves.

CONCLUSION

If you’re wondering why you aren’t meeting your SLAs, then implementing OLAs is a good first step in understanding why. Whichever approach you use for Task Management in Vivantio, you can use the reporting tools you’re already familiar with to review your performance, understand which teams are creating bottlenecks, and fix the issues at the source.

INTRODUCTION

In every company, it’s crucial to have effective, efficient communication, such as the ability to alert your team about new urgent issues, or let a customer know you’ve responded to their request. Thanks to API integration and webhooks, Vivantio makes sending messages to applications such as Slack from your department easy.

This tutorial will show you how to configure this in Slack and provides two examples of using notifications in the Vivantio platform. If your company is using Microsoft Teams, you can find the tutorial here.

To connect Vivantio to Slack, you’ll need:

1. Vivantio ITSM
2. Admin access to your Vivantio Instance

CONFIGURATION IN SLACK

Step 1:

Begin by logging into Slack. You will then go to:

api.slack.com/apps » Create New App

• Fill in the App Name. This is the username that notifications from Vivantio will be posted in Slack from.
• Choose a Development Slack Workspace, which is where you will manage your app. If you don’t already have a Development Slack Workspace, you can create one at slack.com/create#email
• Select Create App

Step 2:

Your new app will appear under Your Apps on the api.slack.com/apps page. Select your app. This will bring you to a new page. Navigate to:

Add features and functionality » Incoming Webhooks » Activate Incoming Webhooks: On » Add New Webhook to Workspace

Step 3:

Choose the channel you want to post to in Slack. Select Allow.

Step 4:

Next, copy the webhook URL that is created, circled in red below. This will later be used to set up the webhook in Vivantio.

CONFIGURATION IN VIVANTIO

Step 5:

Log into Vivantio, open the Admin Area. Navigate to:

Integration & API » Webhooks » Add Webhooks

Then select the ticket type you want the webhook to be available for.

Step 6:

Enter a name for your webhook.

Step 7:

Next, navigate to the Basic Details tab and enter the following information:

• Request URL: Paste here the URL produced when you configured the incoming webhook in Slack.
• HTTP Method: POST
• Response Content Type: application/json

Step 8:

This next step, filling out the parameters tab, is optional. Set up parameters for the webhook by selecting Add. These are either values the technician will be prompted to complete, or populated automatically from the ticket. In this example, we have created a multi-line text field for a technician to enter the message that they wish to send into Slack.

Step 9:

Now, fill out the Request Body tab.

For the Request Content Type field, select application/json. The Body Template will contain the information you wish to send in Slack notification, such as specific text, details from the ticket or a webhook parameter. Screenshots from the Request Body tab of two example webhooks are given below.

Example 1:

A notification message sent into Slack that utilizes the webhook parameter we created in the previous step.

{"text": ""}

Example 2:

A notification sent into Slack that includes details from the ticket. In this case, we use fields from the ticket. The “\n\n” signifies a line break. Note that Steps 2 through 8 were followed to create another Webhook “Slack – High Priority Ticket.” Once the Request Body is filled in, click save.

{"text": "High Priority Ticket Logged – Ticket Details: \n\n ID: {{ticket.displayid}} \n\n Subject: {{ticket.title}} \n\n Caller Name: {{ticket.callername}}"}

Step 10:

The last step before we can use our new webhook is to configure its roles. By default, there will be no roles assigned to the webhook. To update the roles, select the webhook and click Roles. Drag the roles you want the webhook available for into Current Roles.

Now let’s put the webhooks we set up into action!

You can use your webhook to send ad hoc notifications into Slack directly from a ticket window or you can execute your webhook through Trigger Rules. Two examples are given below:

Example 3:

An ad hoc message sent into Slack from a Vivantio ticket window

Actions » Slack Notification

The technician is prompted to fill in the Notification to Slack parameter we set up in the Webhook. Recall that this webhook was configured so that the text entered here will be sent into Slack.

Press OK and voila! This message is sent into Slack.

Example 4:

Sending a notification to an IT team’s channel in Slack any time a high priority ticket is logged.

In this case, you can set up a trigger rule to automatically execute the Webhook when a high priority ticket is logged. Go to:

Admin area » System Areas » Select the ticket type you created the Webhook for » Business Rules » Trigger Rules

To add a Trigger Rule, click “Add,” then:

• • Enter a Rule Name and select when the condition is to be executed, either when the ticket first meets the condition (for example, if you just want people to know the ticket has been created) or when the matching ticket is updated (if you want everyone to see all updates to the ticket)
  • Enter the condition(s) for the trigger. In this example, the trigger rule condition is for tickets with the priority name equal to “high.”

For the trigger rule “actions,” select Webhooks » Webhook you want to fire; in this case, we chose

Slack – High Priority Ticket » Save

Once the trigger rule is set up, the “Slack – High Priority Ticket” Webhook will automatically send a notification with ticket details into Slack any time a “High Priority” ticket is logged.

CONCLUSION

There you have it! Now you can easily communicate to any team in Slack directly from Vivantio.

In May, Vivantio held the UK Vivantio User Group at the Royal Berkshire Conference Centre, part of the Madejski Football stadium in Reading, Berkshire. It was a great day with plenty of customer interaction, discussion on how to make better use of Vivantio and the exciting first look at the upcoming release of Vivantio’s newest toolset and user interface, FLEX.

In case you missed it, here are four key takeaways from the event:

SELF-SERVICE REALLY DOES REDUCE CALLS AND IT OFFICE WALK-INS

Attendees of the UK Vivantio User Group were fortunate to have Alan Shrimpton, Director of Raefen Consulting, as the keynote speaker. He opened the day sharing his experience of implementing Vivantio at two large organisations.

Shrimpton presented some of the challenges he faced and how these were overcome. For one of these organisations, a key measure of success was to significantly reduce IT office walk-ins via use of the Vivantio Self Service Portal.

To overcome this challenge required end-user training for the online platform as well as company-wide communication of the change. Leading up to the launch, there were numerous company communications about the new process, with floor-walkers providing employee support on the day the Self Service Portal went live. As a result of these measures, IT office walk-ins were reduced by 30% in the first month, a significant improvement for such a short period of time.

MOBILE IS KEY TO SERVICE MANAGEMENT

Attendees at the UK User Group attended breakout sessions, with customers working together in groups to identify their top five priorities for development of the Vivantio Platform. This made for an interesting discussion, as different organisations have different priorities and requirements. After the new priorities were discussed and whittled down, the top two areas identified for further development were the Mobile version of the Vivantio Platform and the Vivantio Report Builder.

The upcoming release of the new FLEX will make the mobile solution a much more consistent and complete experience, allowing organisations to customise what information they want to see, including custom forms and fields. Another key point for discussion was generally around flex and how this will improve the day-to-day use of the Vivantio Platform, not only for mobile, but also through improved rendering on any device whether it be a laptop or desktop monitor.

REPORT BUILDER HELP VIDEOS AND OTHER IMPROVEMENTS ARE ON THEIR WAY

Vivantio will provide improved support for use of the Report Builder through a series of short videos and guides, building upon what we currently have. The Report Catalogue will continue to grow, providing additional example reports for customers to use with their own data.

Some of the User Group development suggestions, such as Impact Maps (allowing a user to easily see the relationship between Parent and Child items) and the Ticket History Filter are already in the Vivantio Product Roadmap, aligning customer need to Vivantio’s development vision.

IT’S FLEX TIME

For the final part of the day, Vivantio CTO Andy Walsh shared what Vivantio has done in response to the feedback from our last User Group and what we have coming up on the Product Roadmap. Andy then gave our customers a first-hand look at FLEX, which was very well received.

We are actively testing FLEX within our Support, Development and Implementation teams, and in the next few weeks we will be entering a Closed Beta period with select customers. More details to follow!

All in all, the 2018 UK User Group was a great day. Should you want to find out more about the User Group, FLEX or Product Roadmap, please get in touch with Alexis Mackie, Vivantio Customer Success Manager via email Alexis.Mackie@vivantio.com or phone +44 (0)1934 424 840.

We’re looking forward to the next User Group in 2019 and hope you will be able to join us! Details on the date and location will follow in early 2019

BETTER AUTOMATION TOOLS FOR ALL.

At Vivantio, we constantly interact with teams who have mature service strategies but are searching for better ways to notify stakeholders of their incoming tasks, automate standard processes and define KPIs to adequately benchmark team performance.

To combat common process slowdowns, we have designed the Vivantio visual workflow process tool to streamline tasks and approvals for your standard workflow processes. Let’s discuss how the tool functions and then offer a few examples of applicable processes.

WHAT IS THE VISUAL WORKFLOW TOOL?

Vivantio’s Visual Workflow Tool is a flowchart builder that contains conditional statements to determine the order that tasks are assigned to decision-makers in your workflow process. Your processes can adapt based on previous actions. Therefore, our tool is designed to enforce different workflows depending on task decisions. An example of a conditional workflow includes a product return process that triggers separate tasks depending on the return reason.

Let’s look at how the Visual Workflow Tool address various company operation workflows.

EMPLOYEE ONBOARDING WORKFLOW

A disorganized and incomplete employee onboarding workflow can put an organization at risk for non-compliance or improper preparation. As with all workflows, the on-boarding process requires input between different stakeholders, requiring seamless transitions between each workflow stage.

Vivantio’s Visual Workflow Tool ensures that notifications, approvals and forms are displayed at the correct time and filled out by the proper person, so time-consuming processes such as manual emails, phone calls, and document tracking are completely automated.

Conditional task assignment in onboarding workflows may be used to eliminate unnecessary steps if an employee is a re-hire versus a new hire. If the individual is a new hire, the workflow may assign a task to them to fill out an I9 form and HR may initiate a background check based on the information filled out by the new hire. A re-hire instead may bypass this process entirely and automatically assign a task to the hiring manager to send an offer letter and schedule the starting date. Accepting the offer letter may then trigger additional processes such as assigning tasks to IT for hardware and software allocation.

CHANGE MANAGEMENT WORKFLOW

A successful change management workflow requires capturing details on the affected systems, measuring the risks involved, and managing approvals throughout the process.

The challenge with managing changes is efficiently planning, testing, implementing and then analyzing your KPIs to determine if the change was successful. These processes must occur without impeding normal business operations, hence the benefit of automatic approvals and conditional triggers. Triggering separate workflow processes depending on whether a change is pre-approved, normal or an emergency can help place focus on changes that have a larger impact on the organization.

Pre-approved processes, such as a planned asset upgrade, may trigger a single change manager approval. This prevents operational slow down with a lengthy review process. Scheduled reporting on KPIs associated with the change can be delivered to the change manager to determine if the change is successful.

CAPITAL EXPENDITURE WORKFLOW

Teams with improper evaluation and tracking protocols to process capital expenditure requests are open to budget risks. With Vivantio’s Visual Workflow Tool, you can create appropriate workflows to ensure the correct departments have input on reviewing and processing these requests.

An example process involves an IT employee filling out a form online to request funding for a new help desk solution. An approval notification is then sent to the requester’s manager, which, when approved, sends a secondary approval request to the CFO if the project exceeds a defined price threshold. After the CFO approves the purchase, the project details are delivered to the purchasing department to place an order. The contract may then be managed within your assets database for automated notifications when nearing license renewal.

REPORTING WORKFLOW

While streamlining workflows can rapidly improve a team’s output and success, a powerful reporting tool is essential for tracking service trends for continual improvements. Task completion time is tracked in Vivantio, which provides a useful metric in determining your bottlenecks.

Identifying your service pain points is the first stage in reallocating resources for improved service. Large organizations often track important dates within Vivantio, so scheduled reports can be sent to inform managers of start/finish and deliverable dates for changes and projects.

CONCLUSION

We hope you found this article useful in getting your workflows off the ground in our Visual Workflow Tool. Vivantio’s in-house implementation and support teams consist of ITIL-trained professionals who both have extensive knowledge with optimizing workflows and using the Vivantio platform to leverage the workflow tool to automate your processes. If you need more personal help with a specific workflow, please don’t hesitate to get in touch with us directly.

CAN VIVANTIO BE USED AS AN ALM TOOL?

The answer is yes. Vivantio is flexible enough to be configured to model your development processes, whether you’re using Agile, Scrum, Waterfall, Spiral, or some combination of these. The combination of multiple ticket areas, workflow, asset, and knowledge management gives you almost everything you need.

WHAT CAN’T VIVANTIO DO?

There’s still a couple of things Vivantio can’t do. Some examples are:

• Source control
• Software development

SHOULD I USE VIVANTIO FOR ALM?

Probably not, at least not just Vivantio. Using it with a combination of tools like Team Foundation Server would be a more optimal solution.

That being said, there is definitely a place for Vivantio in your ALM activities. It is very unlikely your developers will want to share their ALM software suite with the support team. However, there is a good chance that Vivantio can help a support team supplement their development team’s efforts.

PREREQUISITES

In order to connect Vivantio to TFS, you’re going to need:

• Admin access to your Vivantio instance
• Admin access to your TFS instance
• A user account in TFS for Vivantio
• The IP address(es) for your TFS servers

BASIC CONFIGURATION

Step 1:

Log in to Vivantio, open the Admin Area, and select TFS under the Integration & API heading on the left menu:

The first screen you’ll see will prompt you for the version of TFS you’re using, and the credentials to use.

• If you’re using TFS 2012/13, or 2015, enter a username and password.
• If you’re using TFS 2017 or VSTS, enter a username and a Personal Access Token. For details on creating a PAT, see the MSDN documentation here.

Having entered those and hit the ‘Save’ button.

Step 2:

The bottom of the screen will update to show a couple of different URLs: the Work Item Alert URL, and the Service Hook URL:

You’ll use one of these URLs when you set TFS up to send information back into Vivantio. We’ll get more into that later. But, while you’re here, you should configure the IP Range for Vivantio to accept requests from, using the ‘IP Range’ button in the menu bar:

Having configured those, you can move on to the next tab, Ticket to Work Item Mapping.

TICKET TO WORK ITEM MAPPING

You can control which types of Vivantio Ticket can be mapped to which types of TFS Work Item by setting up Ticket to Work Item Mappings. This prevents the wrong type of information being transferred or the wrong type of records being created.

When creating a Ticket to Work Item Mapping, you’ll be prompted for a number of different things:

• Project Collection – The Project Collection in TFS
• Project – The Project in TFS
• Work Item Type – The Work Item Type in TFS
• Ticket Type – The type of Ticket within Vivantio

These control the basics of the mapping. On the next tab, Sync Options, there are settings relating to the sync of data between:

You can configure Vivantio to automatically send updates to TFS when the Vivantio Ticket is updated. (Note: This option does not force TFS to update Vivantio. That has to be configured within TFS itself.)

Finally, you can add additional field mappings:

As standard, Vivantio will populate the Work Item Title and Description; if you want to add additional mappings, e.g. for custom fields, you can do so here.

After choosing the appropriate options, hit ‘Save’, and you’re ready to start creating TFS Work Items.

CREATING A NEW WORK ITEM

When viewing a Ticket in Vivantio, under the “More…” menu item, you’ll see the option to “Create New TFS Work Item”:

Clicking that button will bring up the “Create New TFS Work Item” dialog:

You can optionally enter Notes for the Vivantio Ticket History, then hit ‘Save’ to create the TFS Work Item. After a short period of time, you’ll see a TFS tab appear on the Ticket Details:

That includes a link to view the Work Item in TFS, along with options to unlink the ticket from TFS, or to add a direct comment to the TFS Work Item, which can be useful if you didn’t choose to automatically sync actions.

GETTING INFORMATION BACK FROM TFS

The next step in the process is getting information added to TFS sent into Vivantio. This is done using one of two mechanisms, depending on what version of TFS you’re using:

• Work Item Alerts (TFS 2015 or earlier)
• Service Hooks (TFS 2017 / VSTS)

The configuration is pretty similar either way.

Creating a Work Item Alert

(The Microsoft documentation on Work Item Alerts can be found here.)

Work Item Alerts are the ‘older’ of the two mechanisms that can be used for TFS to update Vivantio. If you’re using a version of TFS that supports Service Hooks, we suggest you use those instead. However, if you do want to use Work Item Alerts, you can do so easily.

You can follow the instructions in the MS documentation to configure the basics of the Work Item Alert – which work items the alert is for, and when. The main difference is that rather than having the alert delivered to an email address, you’ll select the ‘SOAP’ option, and enter in your Work Item URL:

TFS will then send a HTTP request to Vivantio when the alert fires, and Vivantio will add the details of the update as a Note on the ticket.

Creating a Service Hook

(The Microsoft documentation on Service Hooks can be found here.)

Service Hooks are a newer feature within TFS–introduced in TFS 2015. We don’t currently have Vivantio listed within TFS as a dedicated option, so on the first page of the Create Service Hook wizard, you’ll choose the “Webhooks” option:

On the next page of the wizard, you’ll choose the type of event the Service Hook triggers on:

Right now, we only support Work Item Commented On and Work Item Updated, but we’re working on introducing support for other events soon. Enter any filters you want for the area or work item type, then move on to the last step:

All you need to do here is add your Service Hook URL, then click Finish. TFS will then start sending updates on Work Items back in to Vivantio.

If you’re using Vivantio and TFS, and you don’t yet have them integrated, give it a try, and see how it can help you improve communications between your Service Desk and your development team!

PREREQUISITES

In order to connect Vivantio to JIRA, you’re going to need:

• Admin access to your Vivantio instance
• Admin access to your JIRA instance
• A user account in JIRA for Vivantio
• The IP address(es) for your JIRA servers

BASIC CONFIGURATION

Step 1:

Log into Vivantio, open the Admin Area, and select JIRA under the Integration & API heading on the left menu:

The first screen you’ll see will prompt you for your JIRA credentials. Enter them and hit ‘Save’.

Step 2:

The bottom of the screen will update to show your unique Webhook URL:

You’ll use this URL when configuring Webhooks within JIRA.

However: before you can do that, you need to configure the IP Range for Vivantio to accept requests from, using the ‘IP Range’ button in the menu bar:

Having configured those options, you can move on to the next tab, Ticket to Issue Mapping.

TICKET TO ISSUE MAPPING

You can control which types of Vivantio Ticket can be mapped to which types of JIRA Issue by setting up Ticket to Issue Mappings. This prevents the wrong type of information being transferred or the wrong type of records being created.

When creating a Ticket to Issue Mapping, you’ll be prompted for a number of different things:

• Ticket Type – the Vivantio Ticket Type
• Project – the Project in JIRA
• Issue Type – the Issue Type in JIRA
• Vivantio ID Custom Field – if you have a custom field in JIRA that you want to use to store the Vivantio Ticket ID, you can enter the (system) field name here. This will usually be in the format ‘customfield_10010’
• Link Issue to Ticket – JIRA has a concept of ‘links’ within a ticket – checking this box will add a link to the Vivantio Ticket to the Issue in JIRA
• Action / Attachment Sync – you can configure Vivantio to automatically send updates to JIRA when the Vivantio Ticket is updated (Note: this option does not force JIRA to update Vivantio though. That has to be configured within JIRA itself.)

After choosing the appropriate options, hit ‘Save’, and you’re ready to start creating JIRA Issues.

CREATING A NEW ISSUE

When viewing a Ticket in Vivantio, under the “More…” menu item, you’ll see the option to “Create New JIRA Issue”:

Clicking that button will bring up the “Create New JIRA Issue” dialog:

You can optionally enter Notes for the Vivantio Ticket History, then hit ‘Save’ to create the JIRA Issue. After a short period of time, you’ll see a JIRA tab appear on the Ticket Details:

That includes a link to view the Issue in JIRA, along with options to unlink the ticket from JIRA, or to add a direct comment to the JIRA Issue – useful if you didn’t choose to automatically sync actions.

GETTING INFORMATION BACK FROM JIRA

The next step in the process is getting information added to JIRA sent into Vivantio. This is done using Webhooks in JIRA. Full documentation on Webhooks can be found here, but we’ll briefly walk you through the steps required to configure them.

Back in the Vivantio Admin Area, you’ll find your unique Webhook URL, which will look something like:

https://url-to-your-vivantio-instance/webhooks/jira/event?accesskey=xxx-yyy-zzz

Make a note of this, head in to the “System” section of the JIRA Admin Area, and find the ‘WebHooks” menu option under “Advanced” (towards the bottom left of the screen). You’ll then have the option to “Create WebHook”, which is going to give you a screen more-or-less similar to the below:

You can enter whatever you want for the “Name”. Vivantio doesn’t use that field. Add your Unique URL in, then head down to the “Events” section, where you choose when you want the Webhook to fire, and for which Issues:

It’s up to you exactly which events you want the Webhook to fire for. For example, you might want to just have the Webhook fire when an Issue is updated or a Comment is added. More advanced users might want to configure the Webhook to only fire for specific transitions as a post function in a Workflow. (Note: see here in the Atlassian docs for more info on that.)

Having done that, you then need to set Vivantio up to listen for that specific event, and decide what actions to take. Back in the JIRA section of the Vivantio Admin Area, select the Webhooks tab, click Add, and choose the type of Ticket you want the Webhook to run for. Completing that step will show you the Add Webhook dialog:

In the name field, you’ll enter either a standard event name (such as ‘issue:updated’) or the name of a transition. For simple integrations, you can then choose to just add the JIRA Comments as Notes–then when the Webhook in JIRA fires, the comments will be added to Vivantio.

If you’re using transitions though, you might want more complicated actions to take place – for example, when an Issue is resolved in JIRA, you might want to change the status of the Vivantio ticket. You can do that using the Actions grid at the bottom of the page.

And there you have it: bi-directional integration between Vivantio and JIRA. If you’re using Vivantio and JIRA, and you don’t yet have them integrated, give it a try, and see how it can help you improve communications between your Service Desk and your development team!

WHAT IS THE REPORT CATALOG?

All Vivantio customers receive the same standard out-of-the-box reports when they start out with Vivantio. However, every customer has different requirements for reporting in Vivantio, and the out-of-the-box reports are meant as a starting point, only. During your implementation, your Implementation Consultant will work with you to assess your reporting requirements and either build reports for you or empower you to build your own reports using the Vivantio Report Builder.

During the nearly 15 years our implementation team have been going through that process, we’ve seen many different reporting requirements from a lot of different customers. Some are pretty unique. Others have made us think: “Wow, we need to make this available to everyone!” While we don’t want to fill up every customer system with hundreds of reports that aren’t relevant, we did want to find a way to share these reports with all our customers.

Hence the introduction of the Vivantio Report Catalog: a “marketplace” of Reports that you can browse through. If you find a report you like, you can import it into your Vivantio instance, where you can then customize it using the Vivantio Report Builder.

HOW DO I USE THE REPORT CATALOG?

Once the Report Catalog is enabled in your system, you need to choose which Roles have access to it. This is done under:

Admin » Reporting » Reports » Access Control

On that screen, when editing a Role, you can grant the Role the “View Report Catalog” permission. Having enabled that for a Role, when a member of that Role is logged in, they will see the Report Catalog link under the Reports section of the left menu. Clicking that link will open the Report Catalog in a new window, allowing you to browse the selection of available reports, preview them, and then import them into your Vivantio instance. After importing a report, it’s available within Vivantio (and the Vivantio Report Builder) like any other report. So, you can customize it, add branding, change the data, whatever you need!

CAN I PUT MY REPORTS INTO THE REPORT CATALOG FOR OTHER VIVANTIO CUSTOMERS TO SEE?

We won’t be making this available by default. If you have a report that you’re particularly proud of or think other customers would find useful, please contact our support team and let them know. We will then review and contact you with a time to chat and see if we can include it.