Workflows in Oomnitza
The workflow module is one of the most powerful tools Oomnitza offers. Workflows allow you to create non-technical automations to numerous elements of your day-to-day thing management.
Contents
Workflow Overview
Workflows are comprised of chainable "Blocks." A workflow always starts with a "Begin" block and concludes with an "End" block.
Begin blocks look for specific changes in Oomnitza, such as the creation, modification, or time-based changes in fields. When the specified event occurs, the subsequent automation blocks will trigger, taking the specified actions, such as firing off emails, updating other fields in the asset, making calls to external APIs, and more.
There are over a dozen different blocks available, which this article will go over in detail. For now, let's start with the fundamentals.
The Workflows Page
Like many elements within Oomnitza, Workflows are located within their individual modules. To create an Asset-focused workflow, navigate to the Assets module, for People-centric workflows, use the People module, and so on. We'll focus on creating Asset workflows.
To access workflows, navigate to the module of your choice, and select Workflow from your navigation bar.
Like most modules in Oomnitza, Workflows come in both block and list views and can be sorted and filtered within those views.
By default, we include a few common workflows that you can utilize, modify, or review to get an understanding of how workflows can be used. You can click on any of those workflows to see what it's doing.
To start building a workflow, click "Add" in the upper right. This will take you to the workflow page. Enter a name, and we'll get started.
Creating your Workflow
Every workflow has three basic parts:
- Begin
- Automation(s)
- End
All workflows start with a beginning and ending block. To start your workflow, drag one or more automation blocks from the left into the "Sandbox" in the middle. For this example, we'll use an update block and a notification block.
To start, drag in your automations, then connect the nodes from Beginning to Automation to End.
To modify or set parameters on your blocks, click "Edit" in the upper right.
Creating a Begin Block
Within the begin block you can define the rules based upon which the workflow will run. That is if it will be run based on a triggering event or on a schedule as well as for which objects the workflow should be run. For a detailed description of the workflow begin block, see here.
Example:
In this article, we'll be creating a workflow that checks when an Asset is 30 days from its end of life date, it sets the status as "EOL Window," and notifies the asset's assignee and our IT team that the asset is nearing its end of life.
For this block, we'll set the action type to "Schedule" because we want it to trigger based on a chronological factor, in this case, it's 30 days before the End of Life Date, which we set in the Rule criteria.
Creating an Automation Block
Once we've set the parameters of the workflow using a begin block, we need to specify what it does. Each automation block has different settings, but in this section, we'll focus on the Update and Notification blocks.
Continuing the above example, our update block will set the status to EOL Window, and our notification block will send an email to IT letting them know that the asset is nearing its EOL date.
Update Block
Name: This is the name of the block, that will appear in the final workflow.
Fields: These are the fields we will update using the update block. For each change we want, we have to specify three parts:
- The Action, either Update or Clean Up. Update changes the field we specify. Clean Up deletes it.
- The Field that we want to update.
- The Result that we want to change the field to. If we're Cleaning Up a field, we won't need to set this.
In the case of our End of Life workflow, we've set the name as a description of what the step does, and for the fields, we set the action to "Update" the field to "Status," and the result to "EOL Window."
Notification Block
Name: The name of the block that will appear in the workflow.
Notify Type: Whether the notification will appear in the Oomnitza Workstream or be sent by email. Typically, email is the preferred method.
Include Link: Determines whether or not a link to the asset will be included in the notification.
Role/Fields/Users/Emails: Determines what user or group of users the notification is sent to. Role will send it to all users with a certain role, Fields will look at the asset in question and will send the message to the user specified in the field. Users let you target specific users, and Emails let you enter an external email.
Subject and Message: The subject and message of the email you want to send. The "Select a metadata field...: option above lets you reference specific data in the object of interest in your message.
We've filled out the form for our example below. We opt to send it to users with the IT Help Desk role, and to the Assigned user in the Assigned To field.
We specify a Subject and Message and use a number of metadata fields to make it clear what asset we're talking about.
End Block
The end block simply indicates that the workflow is done. There are no parameters to set, but it must be connected for the workflow to run successfully.
Validation
Before making a workflow go live we need to validate to make sure that it will work properly. To do so, click "Validate" in the lower right. The results will appear in the validation log. If Validation is successful, you'll see that there are 0 errors and 0 warnings, and the Launch button will turn blue.
If there are errors, they'll appear in pink and identify what's needs to be fixed. In the below example, I've removed the Message and Subject from the notification block we created.
Once your workflow is ready to go, click Launch to put the workflow into effect.
Other Automation Blocks
Oomnitza offers at least 14 different types of blocks to enable numerous different workflow automations. Details on each are listed below. Because this article is meant as an introduction, in-depth details on these blocks have been omitted, but they will be revisited in more advanced articles.
Approval Block
The approval block allows you to pause a workflow pending human verification. When creation an Approval block, you specify a user or group of users to receive a notification email. When the workflow triggers, that user or group of users will be sent an email, as specified in the block, and they'll be prompted to approve or deny it.
The Approval block then allows different actions depending on whether the email was approved or denied.
API Block
The API block is a powerful tool that lets you use your workflows to make calls to external APIs. While the majority of Oomnitza's integrations focus on bringing information into Oomnitza, this block allows you to send data out.
It's important to note that this tool can't store data, so GET requests may be of limited use, depending on the target, but the ability to set metadata fields means that you can take information from your asset and send it as part of your request body.
Zendesk Block
The Zendesk block allows you to automatically create or update a Zendesk ticket, and link an asset to that ticket.
When using this block, you'll be prompted to select whether you want to create or update a Zendesk ticket, then you'll specify how that ticket will be populated.
Slack Block
The Slack Block allows you to automate messages into Slack when changes are made in Oomnitza. This block's functionality is fairly straightforward, however, it allows you to include asset fields in curly brackets (e.g. {Barcode} or {Assigned To} ) to send details on the asset directly to Slack.
Once the workflow has been set up, You'll also need to have Oomnitza Bot installed in Slack, and a channel configured for Oomnitza Bot to send to.
Jira Block
As its name suggests, the Jira Block utilizes Jira's API to create a new ticket in Jira. It offers fields for specifying the Username of the issue's creator in Jira, the issue type, and the Description and Summary of the issue. It also requires you to enter details on your Jira server, including the URL, Project Key, and API token.
Scheduled Report Block
The Scheduled Report block allows Oomnitza to track assets or other objects that meet certain criteria, specified in the Begin Block, and email reports based on objects that meet that criteria.
For example, if we create a Begin Block with:
Actions: Edit
Assigned To has been changed
Then we set the scheduled report block to send the report every Monday, the specified email recipients will receive a report every Monday that contains a list of all Assets that have had their "Assigned To" field changed in the past week.
It's important to note that if there is an update block contained in the same block as a scheduled report block, then it will not trigger the scheduled report, even if the change seemingly would.
Update Child Records Block
Update Child Records allows you to push changes made to parent records to their children. When creating an Update Child Records Block, you're prompted to select which fields you want to be copied from the Parent to the Child.
Threshold Blocks
The Threshold Block allows you to apply a filter, then compares a count of results of that filter to a static threshold and takes a different action depending on whether-or-not it meets that threshold.
For example, when the location of an asset is changed, you could then count assets at a certain location, and if they exceed a certain number, you could send an email notifying interested parties of this fact, but if they do not exceed that number, you could do nothing.
Device Blocks
Oomnitza supports blocks for a number of device manufacturers to pull information directly from the manufacturer using the device's serial number. These allow you to minimize the manual data entry needed to fully document an asset.
These blocks all function in largely the same way, however, we receive different data from each vendor, so there are a few differences in what's available.
Apple Block
The Apple block looks up the serial number for Apple products and uses it to determine what the model is, which it populates into Oomnitza.
Dell Block
The Dell Block uses the Serial Number field and uses it to fetch information on assets from Dell. You can map any number of the fields we receive by selecting "Add Another" at the bottom, and indicating the mapping you want to create.
HP Block
The HP Block lets you indicate the Serial Number and Product Number fields, then uses them to fetch information from HP. Much like the Dell Block, and the Lenovo Block below, you can map any number of the fields we receive by selecting "Add Another" at the bottom, and indicating the mapping you want to create.
Lenovo Block
The Lenovo Block lets you indicate the Serial Number and Product Number fields, then uses them to fetch information from Lenovo. Much like the Dell and HP Blocks, you can map any number of the fields we receive by selecting "Add Another" at the bottom, and indicating the mapping you want to create.
Up Next
Now that we've examined workflows, start thinking about how you can use them to make your day-to-day life easier and more automated. As you brainstorm, let's start looking at how Oomnitza can be customized to meet the specific needs of your organization. Customizing Oomnitza —>
0 Comments