Oxari automation
An effective workflow guide for IT

In many IT departments every ticket goes through manual assignment, manual notification and a manual reminder about an upcoming SLA. That is hours per week burned on "admin" instead of actually resolving problems. The Oxari Workflow module lets you push those repetitive tasks onto a rules engine, routing, escalations and notifications happen automatically. Below we show how to configure it step by step.

What is Oxari Workflow?

Oxari ITSM is a Polish IT service management software, built and developed with mid-size and large organizations on the European market in mind. The Workflow module is a built-in automation rules engine that reacts to events happening in the ticketing system and runs defined actions without human input.

Unlike simple assignment rules (which run once when the ticket is created), Oxari Workflow monitors the entire ticket lifecycle: from arrival, through status changes, customer replies, an approaching SLA deadline, all the way to closure and quality of service rating.

The architecture of a rule in Oxari has three elements:

• Trigger: the event that fires the rule (for example "ticket priority changes to Critical")
• Conditions: filters that narrow when the rule should act (for example "Infrastructure category only", "during business hours only")
• Actions: operations performed automatically (assign technician, change status, send notification, escalate to a supervisor)

Key triggers: where automation starts

Oxari splits triggers into two categories: event-based (react immediately after an event happens) and time-based (fire after a defined time interval).

Event triggers

• New ticket: the most common starting point. Fires routing and the first notification to the technician
• Priority change: when a ticket is "upgraded" to Critical, it automatically lands on the on-call dashboard and triggers an SMS
• Customer comment on a closed ticket: Oxari can automatically reopen the ticket and notify the technician
• Status change: for example "In progress to Waiting for customer" stops the SLA clock and sends an email asking for a reply
• Assignment to a technician: triggers a Teams notification with a direct link to the ticket

Time triggers

• X minutes before SLA breach: for example 30 minutes before the deadline, send an alert to the technician and the team lead
• No activity for N hours: a reminder for the technician or automatic handover to a coordinator
• Morning at 8:00: daily digest of open tickets by priority, sent to IT department heads
• X days after closure: automatic satisfaction survey (CSAT)

If your help desk runs on Jira Service Management rather than Oxari, analogous configurations are in the article on SLAs and queues in JSM.

Every trigger can be combined with conditions using AND/OR operators and parenthesized groups. Oxari does not cap the number of conditions per rule.

Building rules step by step

The recipe below shows a typical first rule worth deploying on day one: automatic routing based on ticket category and user location. This is a good starting point for any organization with more than one IT team.

Configuration best practices

From our experience (clients under NDA) deploying a dozen or so Oxari instances in manufacturing, distribution and services, we have identified a set of principles that separate successful rollouts from those that need reconfiguration after three months.

Start with routing, not with escalations

First make sure every ticket reaches the right group. Without that, escalations and SLAs do not make sense. Routing is the foundation. Build escalations only when the share of manual ticket reassignments drops below 10%.

Use groups, not specific technicians

Assign rules to groups/queues, not to named technicians. A technician can be on leave, on sick leave, can change jobs. Rules that assign by name become a single point of failure. Oxari supports round-robin within a group, so just enable it.

One event, max 3 actions

If one trigger fires 6+ actions, the system is too complex to debug. Split the logic into several rules with narrow scope. Oxari lets you set the rule execution order, so use it.

Document every rule in the "Description" field

Oxari lets you add a description to each rule. Put there: who defined the rule, the date, the business goal and who to notify when there is a problem. In 6 months you will not remember why rule no. 17 only runs at night.

Test on a staging environment before production

Oxari supports rule set export and import between instances. Build and test on a test environment. One mistake in a production rule can flood technicians with hundreds of unjustified notifications in the middle of the night.

Oxari vs Jira Automation vs ManageEngine SDP

The question "which workflow engine is best" has no single answer. The table below compares the three systems in areas that have operational meaning for an IT department of 50-500 people.

Verdict: Oxari wins in the context of Polish organizations: Polish-language interface, support and vendor on the ground, lower learning curve. Jira Automation will be a better fit if the organization already uses the Atlassian ecosystem intensively (Jira Software, Confluence). ManageEngine SDP is the better pick when you need deep integration with ManageEngine tools (CMDB, OpManager, AD Manager).

Common mistakes when deploying Oxari Workflow

Mistake 1: too many rules at once

Teams that try to automate everything in the first week end up with 40 rules nobody understands and which overwrite each other. Start with 5 key routing rules. Add the next ones every 2 weeks, after assessing the effectiveness of the previous ones.

Mistake 2: no filtering conditions, a "catch-all" rule

A rule without conditions runs on every ticket. That is especially dangerous for "Send notification" actions. One mistake and several hundred users get an email that was not meant for them. Always add at least one context condition.

Mistake 3: inactive user as the escalation recipient

Escalation rules wired to a specific technician's email stop working after that person leaves. Use system roles ("IT department head") or groups. Oxari supports dynamic references to roles in recipient fields.

Mistake 4: ignoring workflow logs

Oxari stores the execution history of every rule. Most administrators do not check these logs, so broken rules "sit" in the system for months. Schedule a monthly review: rules with 0 executions in the last 30 days are either useless or have a condition error.

Mistake 5: no testing after a system update

Oxari updates can change field names, API structure or available triggers. After every update run a dry run on the key rules before they go to production.

Summary

Oxari Workflow is one of the most underrated modules on the Polish ITSM market. Organizations that take it seriously - build rules iteratively, test before production and regularly audit logs - really do shorten ticket handling time, cut manual ticket assignment and keep SLAs better under control.

Key takeaways from this article:

• Start with 5 routing rules, not with 40 "for everything" rules
• Use groups, not named technicians: rules must survive staff changes
• Trigger + Conditions + Actions is the formula of every rule, stick to it
• Dry run mode before activation is a requirement, not an option
• Check the logs monthly: dead rules are technical debt

If you want to see how Oxari Workflow will behave in your environment, contact us. We offer a free configuration session in which we will map your processes and show you which rules deliver the fastest return.