CMDB Business Rules: Automate IT Operations

ByTeam Virima

CMDB business rules automate CI promotion decisions, downstream sync actions, notifications, and ITSM event responses in Virima 6.1.1 — eliminating manual CMDB maintenance and improving CMDB accuracy. This FAQ answers the most common questions about how Virima business rules work.

TL;DR

Virima 6.1.1 business rules automate CMDB governance decisions — which CI changes get auto-promoted, which trigger downstream actions, and which require human review — using a no-code condition-trigger-action engine that operates continuously without manual oversight.

What are business rules in a CMDB?

Business rules in a CMDB are configurable logic statements that automate CI maintenance decisions. Each rule defines a condition (the criteria that must be true), a trigger (the event that causes the rule to evaluate), and an action (what the system does when the conditions are met).

Business rules replace the manual judgment calls that CMDB administrators make during routine maintenance — decisions like “should this discovered attribute change be promoted to the CMDB?” or “which team should be notified when this CI’s status changes?”

In Virima 6.1.1, business rules operate continuously against Discovery events, ITSM events, and scheduled tasks. When a trigger fires and the conditions are met, the system executes the defined action automatically — without human intervention.

How do Virima business rules decide which CI changes to auto-promote?

Virima business rules evaluate discovered CI attribute changes against defined conditions to determine whether the change should be automatically promoted to the CMDB or flagged for manual review.

The evaluation logic works as follows:

  • Trigger: Virima Discovery completes a scan and detects a difference between the discovered CI state and the current CMDB record.
  • Condition evaluation: Virima evaluates the change against all active business rules for that CI type and attribute. Conditions can include CI type, attribute name, new value, previous value, change magnitude, and CI criticality.
  • Action: If the condition is met, the rule’s action executes. Auto-promote rules write the discovered change directly to the CMDB. Flag-for-review rules add the change to a review queue and notify the assigned administrator. Reject rules discard the change and log the rejection.

This tiered approach gives IT teams precise control: routine, expected changes auto-promote at machine speed, while unexpected or policy-violating changes surface for human review.

Can business rules trigger actions in Virima ITSM workflows?

Yes. Virima business rules trigger downstream actions in ITSM workflows. When a specific CI attribute change occurs, a business rule can:

  • Create an incident, change, or task record in the Virima ITSM module
  • Notify a team or individual via the configured notification channel
  • Update a related CI record (e.g., update a host CI when a guest VM’s state changes)
  • Trigger a runbook to execute an automated operational procedure
  • Initiate a sync action to a connected ITSM platform (ServiceNow, Jira, Ivanti, HaloITSM)

For example, when Discovery detects that a production server’s OS version changes to a non-approved value, a business rule can simultaneously flag the change for CMDB review, open a security investigation task, notify the patch management team, and trigger a runbook that checks the server’s patch compliance status.

What is runbook automation in Virima?

Runbook automation in Virima is the capability to convert step-by-step IT procedures into automated action sequences that execute in response to ITSM event conditions.

A Virima runbook consists of:

  • A trigger condition — an ITSM event (ticket category, CI state change, schedule) that initiates the runbook.
  • An action sequence — the ordered steps the runbook executes, with conditional branching for exceptions.
  • CMDB context — CI and environment data that the runbook reads to adapt its execution to the specific CI involved.
  • An audit trail — a complete log of every step executed, the result of each step, and any exceptions encountered.

Common runbook use cases in Virima include password resets, server reboots after patch updates, account unlocks, certificate renewals, and software provisioning requests.

How do Virima workflow templates work?

Virima’s Workflow Template Generator allows IT teams to build reusable workflow templates modeled on real business processes — without code.

A workflow template defines:

  • A sequence of steps (approvals, notifications, automated tasks, runbook invocations)
  • Conditions that determine which steps apply (based on CI type, requestor role, environment, or other parameters)
  • Parameter inputs that are supplied at runtime (so the same template handles multiple CI types or requestors)

Once a template is created, it is available in the Virima workflow catalog. Service desk agents, change engineers, and IT administrators invoke templates directly from ITSM records. The template applies the full defined process to the specific record, consistently and without manual coordination.

Templates eliminate the inconsistency that comes from different team members following the same process in different ways. The process is in the template; the template executes the same way every time.

How many business rules can be configured in Virima?

Virima 6.1.1 does not impose a hard limit on the number of business rules. Organizations can configure as many rules as their CI governance requirements demand. Large enterprise deployments typically maintain dozens of active rules across different CI types, attribute categories, and lifecycle stages.

Rules are evaluated in priority order, and administrators can organize rules by CI class, attribute type, or process area to keep the rule library manageable. Virima’s rule evaluation engine processes conditions and triggers at Discovery event speed — rule volume does not introduce latency into CI processing.

What types of IT tasks can be fully automated with Virima business rules?

Virima business rules and runbook automation support full end-to-end automation for:

  • CI promotion decisions — auto-promote approved attribute changes, flag unauthorized changes, reject invalid data.
  • Downstream notifications — notify CI owners, service owners, and ITSM teams when specific attribute changes occur.
  • Decommissioning workflows — trigger the full asset retirement sequence when a CI reaches end-of-life status.
  • Patch compliance enforcement — flag CIs with non-approved software versions and open compliance tasks.
  • Password resets and account unlocks — trigger automated resolution for the highest-volume service desk categories.
  • Post-patch server reboots — schedule and execute reboots after confirmed patch deployment, with pre/post health checks.
  • Certificate renewal sequences — trigger renewal workflows based on expiry monitoring alerts.
  • CMDB sync to connected platforms — keep connected ITSM and ITAM platforms in sync when CI data changes in Virima.

Conclusion

Virima 6.1.1 business rules and runbook automation give IT teams direct control over their CMDB governance logic and ITSM operational procedures — without code, and without manual execution. The result is a CMDB that governs itself, ITSM workflows that execute themselves, and a service desk that handles complexity rather than repetition.

Schedule a Demo at virima.com to see how Virima business rules automate IT operations in your environment.

This article is based on Virima 6.1.1 capabilities. Feature availability may vary by deployment configuration.

Similar Posts