BMC Helix ITSM

Vendor: BMC · Enterprise

BMC Helix ITSM is BMC's IT service management platform, described by BMC as "integrated, AI-driven service management". It is used to run an IT service desk: logging and resolving incidents, investigating problems, controlling changes, and managing IT assets and configuration items.

Access Management (ACCESS)

Managing user access to IT systems. Covers access requests, provisioning, reviews, and deprovisioning.

Activities

Submit Access Request
Submit Access Request via Self Service
Submit Access Request on Behalf of User
Select Access Request Type
Specify Account Subject
Specify Requested Entitlements
Route for Approval
Manager Approval
Entitlement Owner Approval
Security Review
Approve Access Request
Reject Access Request
Return Request for More Information
Generate Fulfillment Work Order
Assign Work Order to Fulfillment Group
Reassign Work Order
Plan Provisioning Tasks
Create Provisioning Task
Create Active Directory Account
Assign Group Membership
Grant Application Entitlement
Assign Software License
Provision Mailbox
Complete Provisioning Task
Set Work Order Pending - Awaiting Information
Set Work Order Pending - Vendor
Resume Work Order
Modify Existing Access
Revoke Access
Disable Account
Verify Account Provisioned
Confirm Entitlements Granted
Notify Requester of Completion
Complete Work Order
Complete Access Request
Request User Confirmation
Receive User Confirmation
Reopen Access Request
Close Access Request
Cancel Access Request
Auto-Close Access Request

Case attributes

Approval Status (string) - Outcome of the approval chain.
Approver (string) - Approver who signed the request.
Assigned Group (string) - Fulfillment support group owning the work.
Assignee (string) - Individual fulfilling the request.
Entitlement (string) - Access element requested (group, role, or license).
Request Type (string) - Nature of the access request.
Service Type (string) - Catalog service / request title.
Target System (string) - System where the account/entitlement is created or changed.
Request Number (string) - System-generated service request identifier (case id).
Task Number (string) - Provisioning task identifier under the work order.
Work Order Number (string) - Fulfillment work order identifier.
Reassignment Count (integer) - Number of fulfillment-group hand-offs.
Company (string) - Customer company the request belongs to.
Requested By (string) - User (often the line manager) who submitted the request.
Requested For (string) - Person the account/entitlement is being provisioned for.
Priority (string) - Handling priority of the request.
Required Resolution Date (datetime) - Committed fulfillment target (SLA date).
Status (string) - Access-request lifecycle state.
Status Reason (string) - Qualifier for the current status.
Work Order Status (string) - Fulfillment work order lifecycle state.
Closed Date (datetime) - Timestamp the request was closed.
Completed Date (datetime) - Timestamp fulfillment completed.
Submit Date (datetime) - Timestamp the request was submitted.

Process-mining benefits (historical)

How long access requests really take, end to end [Efficiency]: See the true lead time from the moment an access request is submitted to the moment it is closed, and where the days actually go - waiting for approval, waiting for a fulfiller, or waiting on the user. Splitting the clock this way shows whether your slow requests are an approval problem or a provisioning problem, so you fix the part that is actually costing time.
Accounts provisioned without the approval they needed [Compliance]: Find the requests where an account or entitlement was created even though the approval chain was never fully signed, or was signed after the work was already done. This is the segregation-of-duties gap auditors ask about, and your own history is the evidence of how often it happens and on which services.
Where approvals stall and who sits on them [Efficiency]: Measure how long each approval step takes and rank approvers and approval stages by the delay they add. Instead of a vague sense that 'approvals are slow', you get the specific stages and people where requests pile up, so you can rebalance approver load or trim steps that add no value.
New joiners still waiting for access on day one [Service]: Isolate the onboarding requests that were not completed by the joiner's start date and trace them back to the approvals, teams, or target systems that ran late. A joiner who cannot log in on their first morning is a productivity and experience hit you can now quantify and target.
Work orders that bounce between fulfillment teams [Efficiency]: See how often a fulfillment work order is passed from one group to another before the access is actually provisioned, and which request types do the most bouncing. Every hand-off is a fresh queue wait, so turning this into a counted pattern shows where the catalog is routing requests to the wrong team.
Leaver access that was never fully revoked [Compliance]: Find the offboarding requests where accounts or entitlements were meant to be revoked but the disable/revoke steps never completed, or completed long after the person left. Lingering leaver access is one of the biggest security exposures, and your history shows exactly which ones slipped.

Process-mining benefits (action)

A daily worklist of joiner access due before a start date [Service]: Every day, surface the open onboarding requests whose target date is closest, sorted by how little time is left, so the team provisions the accounts new joiners need before their first day instead of scrambling after they have already arrived without access.
Chase approvals that are about to breach [Efficiency]: Flag requests that have been sitting in Waiting Approval beyond your threshold and route a reminder to the pending approver, so an access request does not quietly age out because one person never opened their approval queue.
Alert on leaver access that is still active [Compliance]: Watch for offboarding requests where the revoke or disable tasks are not yet complete past their due time, and escalate them immediately, so access for people who have left the organisation is shut off fast rather than lingering as an open risk.
Flag work orders stuck in Pending too long [Efficiency]: Trigger a notification when a fulfillment work order has sat in a Pending state beyond your threshold, so a provisioning job waiting on missing information or a vendor gets chased rather than stalling out of sight.
Step in when a request is bouncing between teams [Service]: Flag any live access request whose work order has already been reassigned more than a set number of times so a coordinator can place it with the right fulfillment group, before the requester experiences yet another hand-off delay.
Catch provisioning that ran ahead of approval [Compliance]: Raise an alert the moment an account or entitlement is created on a request whose approval is not yet signed, so a segregation-of-duties breach is caught and reversed the same day instead of surfacing in an audit months later.

Data tables

SRM:Request - Service request master form (the request case table). One row per service request; carries the Request Number, status, priority, SRD, requester, assignment, and lifecycle timestamps.
SRM:WorkInfo - Service request work-info / activity log. Each entry is a timestamped note, status update, or communication against a request - the primary event source for mining the request flow.
WOI:WorkOrder - Fulfillment work order created to satisfy a service request. One or more work orders per request; carries its own status, assignment, and timestamps - the back-end vehicle for provisioning access and equipment.
AP:Signature - Approval signature records. One row per approval step in a request's approval chain - carries the approver, outcome, and decision timestamp; the source for approval-cycle-time and rejection analysis.
TMS:Task - Fulfillment task under a work order (Task Management System). One row per task; the granular unit of provisioning work (create account, ship laptop) that drives work-order completion when its tasks close.
CTM:People - People master. Callers, submitters, and assignees referenced by incidents.
CTM:Support Group - Support group master. The groups incidents are assigned and reassigned to.

IT Asset Management (ASSET)

CMDB, asset lifecycle

Activities

Create Purchase Requisition - New requisition created on AST:PurchaseRequisition; Status = In Preparation (from Submit/Create Date).
Add Purchase Line Item - Line item added on AST:PurchaseLineItem (product, quantity, unit price) under the requisition.
Submit Requisition for Approval - AST:PurchaseRequisition Status transition In Preparation -> Pending Approval; AP:Signature approval record created.
Approve Requisition - Requisition AP:Signature Approval Status = Approved; AST:PurchaseRequisition Status -> Approved.
Reject Requisition - Requisition AP:Signature Approval Status = Rejected; AST:PurchaseRequisition Status -> Rejected.
Hold Requisition - AST:PurchaseRequisition Status -> Hold (requester pauses the requisition).
Place Order - AST:PurchaseRequisition Status -> On Order once the approved requisition is ordered from the supplier.
Receive Purchase Line Item - AST:PurchaseLineItem marked received; requisition Status -> Received (receiving date recorded).
Close Requisition - AST:PurchaseRequisition Status -> Closed once all line items are received.
Register Asset - Asset CI created on AST:Asset / BMC.CORE:BMC_BaseElement; CI Status = Received (first status on the CI record).
Assemble Asset - CI Status transition Received -> Being Assembled on BMC_BaseElement (hardware being prepared for use); requires CI Status audit logging.
Normalize CI - CMDB Normalization Engine sets the CI Normalization Status (product/category normalized) on the CI in the sandbox dataset (BMC.ASSET.SANDBOX).
Reconcile CI - Identify - CMDB Reconciliation Engine Identify activity matches the source CI to an existing production CI (sets ReconciliationId).
Reconcile CI - Merge - CMDB Reconciliation Engine Merge activity merges the CI into the production dataset BMC.ASSET (creates or updates the production CI).
Assign Asset Owner - Owned By / Used By person set on the CI via AST:AssetPeople association (references CTM:People).
Assign Support Group - Supported By / Managed By group set on the CI (references CTM:Support Group).
Deploy Asset - CI Status transition -> Deployed on BMC_BaseElement (asset in use in the environment); requires CI Status audit logging.
Relate CI to Service - CI related to a business service / other CI via BMC.CORE:BMC_BaseRelationship (CMDB relationship record).
Relate Software License - Software CI connected to a License Certificate; License Engine evaluates compliance for the certificate.
Attach Contract - Maintenance / lease / warranty / support contract related to the asset on AST:Contract.
Record CI Down - Unavailability record created on AST:CIUnavailability; CI Status -> Down (outage start/end captured).
Send for Repair - CI Status transition -> In Repair on BMC_BaseElement; requires CI Status audit logging.
Return to Service - CI Status transition In Repair / Down -> Deployed after the asset is fixed; AST:CIUnavailability outage end recorded.
Add Asset Work Info - Timestamped work-info entry logged on AST:WorkLog against the asset; requires work-info logging enabled.
Return to Inventory - CI Status transition -> In Inventory on BMC_BaseElement (asset returned to stock, available to reserve).
Transfer Asset - CI Status transition -> Transferred on BMC_BaseElement (moved to another company / location / owner).
Mark End of Life - CI Status transition -> End of Life on BMC_BaseElement (asset reached end of useful life, pending disposal).
Dispose Asset - CI Status transition -> Disposed on BMC_BaseElement (asset physically disposed / decommissioned).
Mark CI for Deletion - CI Status transition -> Delete on BMC_BaseElement (marked for removal from the production dataset).

Case attributes

Supported By Group (string) - Support group responsible for the asset; references CTM:Support Group.
CI Class (string) - CMDB class of the asset CI (under BMC.CORE:BMC_BaseElement).
Manufacturer (string) - Manufacturer of the asset.
Primary Capability (string) - Primary Capability of a Computer System CI.
Product Categorization (string) - Product Categorization tiers 1-3 on the CI.
Product Name (string) - Product / model name of the asset.
CI Name (string) - Name of the configuration item on BMC_BaseElement.
Purchase Cost (number) - Purchase cost of the asset.
Asset ID (string) - Asset identifier on AST:Asset (case id for the asset lifecycle).
Asset Tag (string) - Physical asset tag / tag number on AST:Asset.
Reconciliation Identity (string) - CMDB Reconciliation Identity of the production CI (stable id across datasets).
Serial Number (string) - Manufacturer serial number of the CI.
Company (string) - Company the asset belongs to.
Owned By (string) - Person who owns the asset; references CTM:People.
Used By (string) - Person the asset is assigned to / used by; references CTM:People.
Dataset ID (string) - CMDB dataset the CI record belongs to (production vs sandbox).
Location (string) - Region / Site / location of the asset.
Status (string) - CI Status field driving the asset lifecycle on BMC_BaseElement.
Deployed Date (datetime) - Date the CI Status moved to Deployed (in-service date).
Purchase Date (datetime) - Date the asset was purchased (from the requisition / AST:Asset).
Received Date (datetime) - Date the asset / line item was received.
Warranty Expiration Date (datetime) - Warranty / support expiry date from the related contract.

Process-mining benefits (historical)

How long it takes to get an asset from request to deployed [Efficiency]: Measure the real elapsed time from raising a purchase requisition to the CI reaching Deployed, broken down by the procurement and provisioning steps in between. The wait between Approved and On Order, between On Order and Received, and between Register Asset and Deploy Asset becomes a counted, ranked lead-time instead of a guess about why new kit takes so long to reach people.
Where requisitions stall waiting for approval [Efficiency]: See how long requisitions sit in Pending Approval before someone signs off, and which approver groups are the slowest. A cluster of requisitions ageing at one approval gate is a bottleneck you can name and fix rather than a vague sense that procurement drags.
Assets that reached Deployed without passing through the CMDB [Compliance]: Check every deployed asset for the Normalize CI and Reconcile CI - Merge steps that should have landed it in the production dataset BMC.ASSET, and surface the CIs that went live without being normalized or reconciled. These are the unreconciled records that quietly corrupt CMDB trust and audit reporting.
Assets stuck In Inventory instead of being used [Cost]: Trace how long CIs sit in the In Inventory state before they are deployed or disposed, and which product types accumulate most. Kit that is received and then parked in stock for months is capital spent and not working - a spending pattern you can quantify from the status history.
Which assets keep going Down or into In Repair [Service]: Find the CIs that cycle repeatedly through Down and In Repair and group them by product, manufacturer, and support group. A model or a supplier that produces a run of unavailability records is a reliability problem you can target at renewal instead of absorbing outage after outage.
Retirements that never completed disposal [Compliance]: Follow assets that reached End of Life and check whether they went on to Disposed or Delete, or simply stopped. The CIs marked end of life but never disposed are the audit and security gap - hardware still on the books, possibly still connected, with no record of secure decommissioning.

Process-mining benefits (action)

Chase requisitions ordered but not yet received [Cash]: Each day, surface requisitions sitting in On Order past their required date with line items still unreceived, sorted by age, so procurement follows up with suppliers before the delay holds up the people waiting on the kit.
Flag received assets that have not been reconciled into the CMDB [Compliance]: Watch for CIs that have been Received or Registered but have not yet passed Reconcile CI - Merge into the production dataset, and route them to the config team, so every asset in use is a trusted, reconciled CMDB record rather than a sandbox orphan.
Surface idle inventory ready to redeploy [Cost]: Produce a live list of CIs in In Inventory that match open equipment requests, so usable kit already in stock gets redeployed before a new purchase requisition is raised for the same thing.
Alert on assets down longer than their target [Service]: Trigger a notification when a CI has been in Down or In Repair beyond your threshold with no Return to Service, so a long outage gets escalated instead of an asset quietly staying broken and its user without equipment.
Warn before contracts and warranties expire [Cash]: Produce a rolling list of assets whose maintenance, lease, or warranty contract is about to end, so renewals are negotiated or assets retired on purpose rather than lapsing into unsupported, out-of-warranty risk.
Catch software licenses drifting out of compliance [Compliance]: Watch license certificates whose deployed instances are approaching or exceeding purchased entitlements as software CIs are related and deployed, so you true up or reclaim licenses before an audit finds the shortfall.

Data tables

AST:Asset - Asset form - the asset view of a configuration item (the asset case table). One row per asset CI; carries the Asset ID, asset tag, serial number, product, owner/user, location, purchase and warranty data. Sits over the CMDB CI.
AST:PurchaseRequisition - Purchase requisition form driving asset procurement. One row per requisition; carries the requisition Status (In Preparation, Pending Approval, Approved, On Order, Received, Closed, Rejected, Hold) - the event source for the procurement phase.
BMC.CORE:BMC_BaseElement - CMDB base class for all configuration items. Carries the CI Status field that drives the asset lifecycle (Received, Being Assembled, Deployed, In Repair, Down, In Inventory, Transferred, End of Life, Delete, Disposed) and the dataset id. The primary event source for asset lifecycle mining; requires CI Status field auditing / history enabled.
AP:Signature - Approval signature records. One row per approval step in a request's approval chain - carries the approver, outcome, and decision timestamp; the source for approval-cycle-time and rejection analysis.
AST:CIUnavailability - CI unavailability / outage records. One row per outage period; carries the unavailability start and end and the CI - the source for Down time and repair analysis. A CI whose Status is configured as Down produces an unavailability record.
AST:Contract - Contract records (maintenance, lease, warranty, support, software) related to assets - the source for contract expiry and coverage analysis.
AST:PurchaseLineItem - Purchase line items under a requisition. One row per ordered product; carries quantity, unit price, and the received flag/date - the source for receiving events and procurement lead time.
AST:SoftwareLicenseCertificate - Software License Certificate records. Each certificate defines a license type and connection/compliance rules; the License Engine connects software CIs and calculates compliance - the source for software license compliance analysis.
AST:WorkLog - Asset work-info / activity log. Each entry is a timestamped note or status update against an asset CI - a secondary event source. Requires work-info logging enabled.
BMC.CORE:BMC_BaseRelationship - CMDB relationship records linking CIs to each other and to business services - the source for impact and service-dependency analysis (e.g. which service an asset supports).
BMC.CORE:BMC_ComputerSystem - Computer System CI class (servers, laptops, desktops) - the most common asset class under BMC_BaseElement. Carries Primary Capability, host name, and hardware attributes used for deployment and license compliance.
CTM:People - People master. Callers, submitters, and assignees referenced by incidents.
CTM:Support Group - Support group master. The groups incidents are assigned and reassigned to.

Change Management (CHANGE)

Change requests, approvals, implementation

Activities

Create Change Request - New change record created on CHG:Infrastructure Change; from Create Date / first CHG:ChangeRequest_AuditLog row with Status = Draft.
Set Change Type - Change Type field set on CHG:Infrastructure Change (Normal, Standard, Emergency, Latent, No Impact, Expedited).
Set Risk Level - Risk Level field set on CHG:Infrastructure Change (Risk Level 1-5, from the risk questionnaire); drives the required approval path.
Set Impact - Impact field set on CHG:Infrastructure Change.
Set Urgency - Urgency field set on CHG:Infrastructure Change.
Set Priority - Priority field on CHG:Infrastructure Change, derived from Impact and Urgency.
Assign Change Coordinator - Change Coordinator field set on CHG:Infrastructure Change (references CTM:People).
Assign Change Manager - Change Manager field set on CHG:Infrastructure Change (references CTM:People).
Relate Configuration Item - Affected CI / ServiceCI associated to the change; row in CHG:Associations.
Relate Incident - Originating or related incident linked to the change; row in CHG:Associations referencing HPD:Help Desk.
Submit Change Request - Status transition Draft -> Request For Authorization on CHG:ChangeRequest_AuditLog.
Review Change Request - Change reviewer assesses the request in status Request For Authorization; review-phase AP:Signature record created via CHG:ChangeAPDetail.
Authorize Change - Review Approved - Review-phase AP:Signature Approval Status = Approved (CHG:ChangeAPDetail).
Reject Change - Review - Review-phase AP:Signature Approval Status = Rejected; status moves to Rejected on CHG:ChangeRequest_AuditLog.
Request Business Approval - Status transition to Request For Change; business-approval AP:Signature records created (CHG:ChangeAPDetail).
Business Approve Change - Business-approval AP:Signature Approval Status = Approved (CHG:ChangeAPDetail).
Reject Change - Business - Business-approval AP:Signature Approval Status = Rejected; status to Rejected on CHG:ChangeRequest_AuditLog.
Begin Planning - Status transition to Planning In Progress on CHG:ChangeRequest_AuditLog.
Create Implementation Task - Implementation / assessment task created in TMS:Task for the change (Task Type, parent Infrastructure Change ID).
Assign Task to Implementer - TMS:Task Assignee / Assigned Group set (references CTM:People, CTM:Support Group).
Set Scheduled Dates - Scheduled Start Date and Scheduled End Date set on CHG:Infrastructure Change.
Schedule For Review - Status transition to Scheduled For Review on CHG:ChangeRequest_AuditLog.
Schedule For Approval - Status transition to Scheduled For Approval on CHG:ChangeRequest_AuditLog.
Request Implementation Approval - Implementation-approval (CAB) AP:Signature records created for the change (CHG:ChangeAPDetail).
Approve Change - CAB - Implementation-approval AP:Signature Approval Status = Approved (CAB sign-off in CHG:ChangeAPDetail).
Reject Change - Implementation - Implementation-approval AP:Signature Approval Status = Rejected; status to Rejected on CHG:ChangeRequest_AuditLog.
Schedule Change - Status transition to Scheduled on CHG:ChangeRequest_AuditLog (approved, awaiting implementation window).
Start Implementation - Status transition to Implementation In Progress on CHG:ChangeRequest_AuditLog; Actual Start Date recorded on CHG:Infrastructure Change.
Complete Task - TMS:Task status set to Closed / Completed for an implementation task.
Add Work Info - Work-info entry logged in CHG:WorkLog (timestamped note / status update); requires work-info logging enabled.
Complete Implementation - Status transition to Completed on CHG:ChangeRequest_AuditLog; Actual End Date recorded on CHG:Infrastructure Change.
Record Change Outcome - Status Reason set on CHG:Infrastructure Change (Successful, Successful with Issues, Unsuccessful).
Back Out Change - Status Reason = Backed Out on CHG:Infrastructure Change (backout path).
Perform Post-Implementation Review - Final / close-down review; Status Reason Final Review Required -> Final Review Complete on CHG:Infrastructure Change, or a PIR TMS:Task closure.
Close Down Approve Change - Close-down AP:Signature Approval Status = Approved (CHG:ChangeAPDetail).
Close Change Request - Status transition to Closed on CHG:ChangeRequest_AuditLog; Closed Date recorded.
Cancel Change Request - Status transition to Cancelled on CHG:ChangeRequest_AuditLog.
Set Pending - Status transition to Pending on CHG:ChangeRequest_AuditLog with a Status Reason.
Resume from Pending - Status transition out of Pending back to the prior working status on CHG:ChangeRequest_AuditLog.

Case attributes

Assigned Group (string) - Support group implementing the change; references CTM:Support Group.
Change Assignee (string) - Individual implementing the change; references CTM:People.
Change Type (string) - Class of change; drives the approval path (Change Type field).
Impact (string) - Business impact of the change.
Risk Level (string) - Assessed risk of the change (1 low - 5 high) from the risk questionnaire.
Urgency (string) - Time sensitivity of the change.
Summary (string) - Short description of the change.
Infrastructure Change ID (string) - System-generated change request identifier (case id) on CHG:Infrastructure Change.
Company (string) - Customer company the change belongs to.
Change Coordinator (string) - Person coordinating the change (typically the creator); references CTM:People.
Change Manager (string) - Change manager accountable for progression; references CTM:People.
Submitter (string) - Login of the user who submitted the change.
Priority (string) - Handling priority derived from Impact and Urgency.
Service (string) - Business service (ServiceCI) affected by the change.
Status (string) - Change request lifecycle state on CHG:Infrastructure Change.
Status Reason (string) - Qualifier for the current status (e.g. the completion outcome).
Actual End Date (datetime) - Actual time implementation finished.
Actual Start Date (datetime) - Actual time implementation began.
Closed Date (datetime) - Timestamp the change was closed.
Scheduled End Date (datetime) - Planned implementation window end on CHG:Infrastructure Change.
Scheduled Start Date (datetime) - Planned implementation window start on CHG:Infrastructure Change.
Submit Date (datetime) - Timestamp the change request was submitted.

Process-mining benefits (historical)

Where changes stall between approval stages [Efficiency]: See how long changes wait at each gate - review, business, and CAB approval - before someone signs off, and which approver groups are the slowest. The wait between reaching an approval status and the sign-off landing becomes a counted, ranked bottleneck instead of a vague sense that 'approvals take forever'.
Failed and backed-out changes, and where they come from [Service]: Find the changes that completed Unsuccessful or were Backed Out and trace them to the coordinators, groups, risk levels, and change types that produce them. A cluster of failures on one team or one class of change is a rework and outage risk you can target directly.
Changes that skipped an approval they should have had [Compliance]: Check every closed change against the approval path its type and risk level require, and surface the ones that reached Scheduled or Implementation In Progress without the expected review, business, or CAB sign-off. This is the conformance evidence auditors ask for, built from your own record rather than a sampled spot-check.
How often changes bounce back into planning [Efficiency]: Measure how many changes move forward to Scheduled For Review or Scheduled and then fall back to Request For Change or Planning In Progress to redo their planning. Each loop is wasted lead time, and the categories that loop most point at weak intake or thin change templates.
Emergency changes versus the normal path [Service]: Split your change history by change type to see how large a share run as Emergency or Expedited, how their success rate compares to normal changes, and which services rely on the fast path. A high emergency ratio usually means normal changes are too slow - a fixable planning problem, not an unavoidable one.
Implementation tasks that overrun their window [Cost]: Compare each change's scheduled window against its actual start and end, and break the overruns down by implementer group and task type. You learn which teams routinely start late or run long, and which kinds of change are chronically under-scoped.

Process-mining benefits (action)

A daily worklist of changes awaiting approval [Service]: Every day, surface the changes parked in Request For Authorization, Request For Change, or Scheduled For Approval, sorted by how long they have waited and their scheduled window, so approvers clear the ones blocking imminent work before those windows are missed.
Flag emergency changes for retrospective review [Compliance]: Route every change opened as Emergency or Expedited to a same-week review queue, so the fast-path shortcuts get the after-the-fact scrutiny your policy requires and nothing bypasses governance unnoticed.
Chase changes stuck in Pending too long [Efficiency]: Trigger a notification when a change has sat in the Pending state beyond your threshold, so work suspended on a dependency gets resumed rather than quietly ageing past its scheduled window.
Alert when an implementation window is about to open with tasks incomplete [Service]: Watch scheduled changes whose start time is near while their implementation tasks are still open, and warn the coordinator so the change is either ready or rescheduled instead of starting half-planned.
Review every backed-out change the day it happens [Service]: Route each change that records a Backed Out or Unsuccessful outcome to an immediate review, so a failed change gets its post-implementation review and root-cause attention while the detail is fresh.
Catch completed changes that never got closed out [Compliance]: Produce a live list of changes sitting in Completed past their final review window without moving to Closed, sorted by age, so the post-implementation review and close-down are finished rather than left hanging in an audit-visible limbo.

Data tables

CHG:ChangeRequest_AuditLog - Field-level audit / status history for changes. One row per changed field, with old value, new value, and timestamp - the primary event source for reconstructing status and field transitions. Requires audit logging enabled.
CHG:Infrastructure Change - Core change request record form (the change case table). One row per change; carries the Infrastructure Change ID, status, change type, risk, priority, coordinator/manager, scheduled and actual dates.
CHG:WorkLog - Change work-info / activity log. Each entry is a timestamped note, status update, or communication against a change - a secondary event source. Requires work-info logging enabled.
AP:Signature - Approval signature records. One row per approval step in a request's approval chain - carries the approver, outcome, and decision timestamp; the source for approval-cycle-time and rejection analysis.
CHG:Associations - Relationship records linking a change to configuration items, affected services, incidents, and other requests - the source for CI and incident linkage analysis.
CHG:ChangeAPDetail - Approval-phase detail for changes. One row per approval phase (Review, Business, Implementation, Close Down) joining the change to its AP:Signature records - the source for approval-step timing and outcomes.
TMS:Task - Fulfillment task under a work order (Task Management System). One row per task; the granular unit of provisioning work (create account, ship laptop) that drives work-order completion when its tasks close.
CTM:People - People master. Callers, submitters, and assignees referenced by incidents.
CTM:Support Group - Support group master. The groups incidents are assigned and reassigned to.

Incident Management (INCIDENT)

Ticket creation, assignment, resolution

Activities

Record Incident
Record Incident via Self Service
Record Incident via Email
Record Incident via Phone
Record Incident via Systems Management Event
Record Incident via Walk In
Set Impact
Set Urgency
Set Priority
Set Operational Categorization
Set Product Categorization
Set Service
Assign to Support Group
Assign to Assignee
Reassign to Support Group
Reassign to Assignee
Assign to Vendor
Begin Investigation
Add Work Info
Relate Configuration Item
Search Knowledge Base
Relate Known Error
Request Customer Information
Set Pending - Customer Response
Set Pending - Vendor
Set Pending - Third Party
Resume from Pending
Escalate Incident
Declare Major Incident
Clear Major Incident
Attach Service Target
SLA Response Met
SLA Response Breached
SLA Resolution Met
SLA Resolution Breached
Provide Workaround
Resolve Incident
Record Resolution
Set Resolution Categorization
Request User Confirmation
Receive User Confirmation
Reopen Incident
Close Incident
Cancel Incident
Auto-Close Incident

Case attributes

Assigned Group (string) - Support group currently owning the incident.
Assignee (string) - Individual currently working the incident.
Owner Group (string) - Support group accountable for the incident.
Operational Categorization (string) - Operational category tiers 1-3.
Product Categorization (string) - Product category tiers 1-3.
Reported Source (string) - Channel the incident arrived through.
Impact (string) - Business impact of the incident.
Service Type (string) - Nature of the incident.
Urgency (string) - Time sensitivity of the incident.
Incident Number (string) - System-generated incident identifier (case id).
Reassignment Count (integer) - Number of support-group hand-offs.
Reopen Count (integer) - Number of times the incident was reopened after resolution.
Company (string) - Customer company the incident belongs to.
Submitter (string) - Login of the user who recorded the incident.
Priority (string) - Handling priority derived from Impact and Urgency.
Service (string) - Business service affected by the incident.
Resolution Categorization (string) - Resolution / closure categorization.
SLA Target Date (datetime) - Committed response/resolution target from the service target.
Status (string) - Incident lifecycle state.
Status Reason (string) - Qualifier for the current status (e.g. why pending).

Process-mining benefits (historical)

Where tickets ping-pong between support groups [Efficiency]: See how often an incident is passed from one support group to another before someone actually resolves it, and which routing paths do the bouncing. Every hand-off is a fresh queue wait, so turning 'it gets reassigned a lot' into a counted, ranked pattern shows exactly which groups are miscategorised into or wrongly landed on.
The real cost of time spent on hold [Efficiency]: Measure how many days incidents sit in Pending - waiting on the caller, a vendor, or a third party - and how much of your total resolution time is hold time rather than work time. The reasons that pause tickets the longest become your first target for chasing callers faster or tightening vendor SLAs.
SLA breaches, and the priorities that miss most [Service]: Rank response and resolution SLA misses by priority and support group to see where commitments break down. Instead of a single breach percentage you get the specific priority bands and teams that drive the failures, and how far past target the worst ones run.
Reopened incidents that were never really fixed [Service]: Find the incidents that were marked Resolved and then reopened, and trace them back to the groups, categories, and resolution codes that produce false fixes. A high reopen rate is rework you are paying for twice and a customer-satisfaction problem hiding in the numbers.
How much the first line resolves versus escalates [Efficiency]: Compare the incidents the service desk closes on its own against those escalated to second line, split by category. A low first-line resolution rate points at missing knowledge articles or over-eager escalation - both fixable once you can see where they happen.
Which intake channels create the slowest incidents [Cost]: Break resolution time and reassignment down by how the incident was reported - self service, email, phone, or a monitoring event. You learn which channels arrive well-formed and route cleanly, and which ones cost extra handling because they land under-categorised.

Process-mining benefits (action)

A daily worklist of incidents about to breach SLA [Service]: Every day, surface the open incidents whose response or resolution target is closest to breaching, sorted by priority and time remaining, so the team saves the commitments that are still savable instead of finding out after the clock has already run out.
Alert on incidents stuck in Pending too long [Efficiency]: Trigger a notification when an incident has sat in a Pending state beyond your threshold, so a ticket waiting on a caller or vendor gets chased rather than quietly ageing off everyone's radar.
Step in when a ticket is bouncing between teams [Efficiency]: Flag any live incident that has already been reassigned more than a set number of times so a coordinator can place it with the right group, before the customer experiences a third or fourth hand-off delay.
Review every reopened incident the day it reopens [Service]: Route each incident that flips from Resolved back to In Progress to a quick review the same day, so a botched fix gets proper attention immediately and you catch the pattern behind it early.
Escalate major and high-impact incidents the moment they land [Service]: Watch for incidents that are declared major or opened at the highest impact and push them straight to the major-incident process and the right responders, so the biggest hits get the fastest possible start.
Chase new incidents that no one has picked up [Efficiency]: Produce a live list of incidents that were recorded but still have no assignee, sorted by age and priority, so nothing sits in New or Assigned limbo because it never reached a person.

Data tables

HPD:Help Desk - Core incident record form (the incident case table). One row per incident; carries the Incident Number, status, priority, assignment, and timestamps.
HPD:WorkLog - Incident work-info / activity log. Each entry is a timestamped note, status update, or communication against an incident - the primary event source for mining the incident flow.
HPD:Assignment_Log - Assignment / reassignment history for incidents. One row per hand-off between support groups or assignees - the source for reassignment and hand-off analysis.
HPD:Help Desk Audit Log - Field-level audit history for incidents. One row per changed field, with old value, new value, and timestamp - reconstructs status and assignment transitions.
SLM:Measurement - Service Level Management measurement records. One row per service target attached to an incident; carries the target time and met/breached outcome.
CTM:People - People master. Callers, submitters, and assignees referenced by incidents.
CTM:Support Group - Support group master. The groups incidents are assigned and reassigned to.

Problem Management (PROBLEM)

Root cause analysis, known errors

Activities

Log Problem Investigation - PBM:Problem Investigation record created (Status=Draft). One row per problem = the case (Problem Record Logged).
Log Problem from Recurring Incidents - PBM:Problem Investigation raised from linked incidents (InvestigationDriver=Incident) via HPD:Help Desk_Associations.
Relate Incident to Problem - HPD:Help Desk_Associations row linking an incident to the problem; drives RelatedIncidentCount.
Move to Under Review - PBM:Problem Investigation Status transition Draft->Under Review (from PBM:Problem Investigation_AuditLog).
Assign to Support Group - PBM:Problem Investigation Assigned Group set and Status->Assigned (Assigned to Support Group).
Assign to Problem Investigator - PBM:Problem Investigation Assignee set to the specialist investigating.
Reassign Problem Coordinator - PBM:Problem Investigation Problem Coordinator changed (Coordinator Reassigned); increments ReassignmentCount.
Reassign to Support Group - PBM:Problem Investigation Assigned Group changed (from audit log); increments ReassignmentCount.
Begin Investigation - PBM:Problem Investigation Status Assigned->Under Investigation (Investigation Commenced).
Add Work Info - PBM:Problem_WorkLog entry against the problem - requires work-info logging on the problem.
Relate Configuration Item - Affected service / CI recorded on PBM:Problem Investigation (ServiceCI).
Identify Root Cause - Root cause recorded on PBM:Problem Investigation (RootCauseCategory set) - Root Cause Identified.
Set Pending - PBM:Problem Investigation Status->Pending with a status reason (e.g. Client Action Required, Infrastructure Change) - from audit log.
Resume from Pending - PBM:Problem Investigation Status Pending->Under Investigation (from audit log).
Define Workaround - Interim workaround recorded on the problem / known error (WorkaroundStatus) - Workaround Defined.
Promote to Known Error - PBM:Known Error record created; PBM:Problem Investigation Status=Completed, reason 'Known Error' (Known Error Promoted).
Update Solution Database - PBM:Solution Database entry created / updated with the solution or workaround (Solution Database Updated).
Schedule Known Error for Correction - PBM:Known Error Status->Scheduled For Correction (pending infrastructure change or vendor).
Assign Known Error to Vendor - PBM:Known Error Status->Assigned to Vendor (third-party dependency).
Mark No Action Planned - PBM:Known Error Status->No Action Planned (reason Funding Not available).
Initiate Change Request - Change raised to implement the permanent fix (RelatedChangeRequestId; CHG:Infrastructure Change association) - Change Request Initiated.
Correct Known Error - PBM:Known Error Status->Corrected once the fix is applied.
SLA Target Breached - Service target on the problem breached (SLM:Measurement; IsSLABreached=true).
Complete Root Cause Analysis - PBM:Problem Investigation Status Under Investigation->Completed.
Verify Resolution - Resolution verified against the problem / linked incidents (Resolution Verified).
Conduct Post-Implementation Review - Post-Implementation Review conducted (PBM:Known Error Corrected reason 'Pending PIR') - Post-Implementation Review Conducted.
Close Problem Investigation - PBM:Problem Investigation Status->Closed (Problem Record Closed).
Close Known Error - PBM:Known Error Status->Closed.
Cancel Problem Investigation - PBM:Problem Investigation Status->Cancelled (reason Duplicate Investigation) - Problem Record Cancelled.

Case attributes

Assigned Group (string) - Support group currently owning the investigation (SupportGroup).
Assignee (string) - Individual specialist working the investigation.
Problem Coordinator (string) - Person accountable for coordinating the investigation (ProblemCoordinator).
Root Cause Category (string) - Category of the identified root cause (RootCauseCategory).
Impact (string) - Business impact of the underlying problem.
Investigation Driver (string) - What triggered the investigation (InvestigationDriver).
Urgency (string) - Time sensitivity of the problem.
Problem Investigation ID (string) - System-generated problem investigation identifier (case id).
Investigation Cycle Time (integer) - Elapsed days from logged to closed (InvestigationCycleTime).
Reassignment Count (integer) - Number of coordinator / support-group hand-offs (ReassignmentCount).
Related Incident Count (integer) - Number of incidents linked to the problem (RelatedIncidentCount).
Company (string) - Customer company the problem belongs to.
Region (string) - Geographic region of the problem (Region).
Priority (string) - Handling priority of the problem.
Related Change Request (string) - Change request raised to implement the permanent fix (RelatedChangeRequestId).
Service (string) - Business service / configuration item affected (ServiceCI).
SLA Breached (boolean) - Whether a service target on the problem was breached (IsSLABreached).
SLA Due Date (datetime) - Committed target date for the investigation (SLADueDate).
Known Error Status (string) - Lifecycle state of the related PBM:Known Error record.
Status (string) - Problem investigation lifecycle state.
Status Reason (string) - Qualifier for the current status.
Workaround Status (string) - State of the interim workaround (WorkaroundStatus).

Process-mining benefits (historical)

How long problems wait before anyone investigates [Efficiency]: Measure the gap between logging a problem and actually starting root cause analysis - the time it drifts through Draft, Under Review, and Assigned before someone begins work. Long front-end waits are where problems quietly age, and seeing them ranked shows which support groups pick up investigations slowly.
Investigations that stall in Pending [Efficiency]: Measure how many days investigations sit in Pending - waiting on a dependency, an infrastructure change, or a vendor - and how much of total investigation time is hold time rather than analysis. The status reasons that pause problems the longest become your first target for unblocking them.
Reassignment churn between coordinators and groups [Efficiency]: See how often a problem is handed between problem coordinators or support groups before it is resolved, and which routing paths do the bouncing. Every hand-off restarts context and adds queue time, so turning churn into a counted pattern shows where ownership is unclear.
Problems closed without a documented root cause [Service]: Find the investigations that reached Closed without a recorded root cause, known error, or solution entry. These are the ones most likely to come back as fresh incidents, and spotting the groups and categories that produce them tells you where diagnosis is being skipped.
Which problems carry the most recurring incidents [Cost]: Rank open and past problems by how many incidents they are linked to, so you can see where a single unresolved root cause is generating the most repeat tickets. Those are the investigations where a permanent fix pays back the fastest in avoided incident handling.
SLA breaches on problem targets, by priority and group [Compliance]: Rank the problem investigations that breached their service target by priority and support group to see where commitments break down. Instead of a single breach percentage you get the specific bands and teams driving the misses, and how far past target the worst run.

Process-mining benefits (action)

A daily worklist of problems nearing their SLA target [Service]: Every day, surface the open problem investigations whose target date is closest, sorted by priority and time remaining, so coordinators push the ones still savable before the clock runs out rather than reviewing breaches after the fact.
Alert on investigations stuck in Pending too long [Efficiency]: Trigger a notification when a problem has sat in a Pending state beyond your threshold, so an investigation waiting on a dependency or vendor gets chased rather than quietly ageing off everyone's radar.
Raise a problem when incidents keep recurring [Cost]: Watch for clusters of similar incidents that cross a recurrence threshold with no problem investigation attached, and flag them for a coordinator, so the root cause gets opened before the same incident is handled for the tenth time.
Chase known errors scheduled for correction with no change raised [Service]: Produce a live list of known errors marked Scheduled For Correction that still have no change request behind them, so a documented fix does not stall between 'we know the cause' and 'someone is actually implementing it'.
Step in when an investigation keeps bouncing [Efficiency]: Flag any live problem that has already been reassigned more than a set number of times so a manager can place it with the right coordinator and group, before it picks up another hand-off delay.
Make sure every completed investigation gets its review before close [Compliance]: Route each investigation that reaches Completed but is missing a post-implementation review to the coordinator before it can close, so the process discipline that prevents repeat problems is not skipped under time pressure.

Data tables

HPD:Help Desk - Core incident record form (the incident case table). One row per incident; carries the Incident Number, status, priority, assignment, and timestamps.
PBM:Known Error - Known error records. A known error is a diagnosed problem with a documented root cause and workaround; carries its own status lifecycle through to correction and closure.
PBM:Problem Investigation - Core problem investigation record (the problem case table). One row per problem; carries the Problem Investigation ID, status, priority, coordinator, assignment, root cause, and timestamps.
PBM:Problem_WorkLog - Problem work-info / activity log. Each entry is a timestamped note, status update, or communication against a problem investigation - the primary event source for mining the investigation flow.
HPD:Help Desk_Associations - Association records linking problem investigations to the incidents that drove them. One row per incident-to-problem relationship - the source for RelatedIncidentCount and recurring-incident analysis.
PBM:Problem Investigation_AuditLog - Field-level audit history for problem investigations. One row per changed field, with old value, new value, and timestamp - reconstructs status, assignment, and coordinator transitions.
PBM:Solution Database - Solution database entries. A repository of solutions and workarounds captured from problem investigations and known errors for reuse against future incidents.
SLM:Measurement - Service Level Management measurement records. One row per service target attached to an incident; carries the target time and met/breached outcome.
CTM:People - People master. Callers, submitters, and assignees referenced by incidents.
CTM:Support Group - Support group master. The groups incidents are assigned and reassigned to.

Service Request (REQUEST)

Catalog items, fulfillment

Activities

Submit Service Request
Submit Request via Self Service Catalog
Submit Request on Behalf of User
Save Request as Draft
Set Service Request Definition
Set Requested For
Request In Review
Set Priority
Set Categorization
Request Waiting for Approval
Approve Request
Reject Request
Add Approval Level
Request Assigned
Reassign Request
Create Work Order
Assign Work Order
Create Fulfillment Task
Assign Fulfillment Task
Fulfillment In Progress
Work Fulfillment Task
Complete Fulfillment Task
Complete Work Order
Information Requested from User
Set Request Pending
Request Resumed
Escalate Request
Attach Service Target
SLA Response Breached
SLA Resolution Breached
Solution Implemented
Service Request Resolved
Record Resolution
Request User Confirmation
Resolution Confirmed by User
Reopen Service Request
Service Request Closed
Auto-Close Service Request
Service Request Cancelled

Case attributes

Approval Status (string) - Outcome of the approval chain.
Assigned Group (string) - Fulfillment support group currently owning the request.
Assignee (string) - Individual currently working the request.
Categorization (string) - Operational / product categorization tiers.
Submission Channel (string) - Channel the request arrived through.
Impact (string) - Business impact if the request is not fulfilled.
Service Type (string) - Nature of the service request.
Urgency (string) - Time sensitivity of the request.
Request ID (string) - Internal instance id of the request record.
Request Number (string) - System-generated service request identifier (case id).
Title (string) - Short title of the requested service (from the SRD).
Handoff Count (integer) - Number of support-group reassignments (hand-offs).
Reopen Count (integer) - Number of times the request was reopened after resolution.
Company (string) - Customer company the request belongs to.
Requester Department (string) - Department of the requester / beneficiary.
Requested By (string) - The person who submitted the request.
Requested For (string) - The person the service is being requested for (the beneficiary).
Priority (string) - Handling priority of the request.
Service Request Definition (string) - Catalog item (SRD) the request was raised from.
Close Code (string) - Closure code recorded when the request is completed.
Resolution Category (string) - Resolution / fulfillment categorization.
Is SLA Breached (boolean) - Flag indicating the request breached its service target.
SLA Target Date (datetime) - Committed response/fulfillment target from the service target.
Status (string) - Service request lifecycle state.
Status Reason (string) - Qualifier for the current status (e.g. why pending).
Closed Date (datetime) - Timestamp the request was closed.
Completed Date (datetime) - Timestamp the request was completed / resolved.
Submit Date (datetime) - Timestamp the request was submitted (case start).

Process-mining benefits (historical)

Where approvals stall the whole request [Compliance]: See how long requests sit waiting for approval, which approval levels hold things up, and how often a request is rejected or bounced back for more information. When onboarding access needs a sign-off before anything gets provisioned, the approval step is often the single biggest slice of the total wait - and the easiest to fix once you can see who is slow.
Requests that ping-pong between fulfillment teams [Efficiency]: Count how often a request is reassigned from one support group to another before it is actually worked, and which routing paths do the bouncing. Every hand-off is a fresh queue wait, so turning 'it gets reassigned a lot' into a ranked pattern shows which catalog items are routed to the wrong team from the start.
Work orders and tasks that stall fulfillment [Efficiency]: Follow the request into its work orders and fulfillment tasks to find where provisioning actually slows down - a laptop-build task that waits days, an account-creation task nobody picks up. You learn which task types and teams sit between Fulfillment In Progress and a completed work order the longest.
Which intake channels create the slowest requests [Cost]: Break fulfillment time and hand-offs down by how the request came in - self service catalog, an agent raising it on someone's behalf, phone, or email. You learn which channels arrive well-formed against a clean catalog item and which ones cost extra handling because they land under-specified.
Which catalog items miss their SLA most [Service]: Rank response and fulfillment SLA misses by catalog item (SRD) and priority to see where commitments break down. Instead of one breach percentage you get the specific offerings and priority bands that drive the failures, and how far past target the worst ones run.
Reopened and cancelled requests that never delivered [Service]: Find the requests that were marked resolved and then reopened, and the ones cancelled before they ever completed, and trace them to the catalog items and teams that produce them. A high reopen or cancel rate is provisioning you paid for that did not stick - and a poor day-one experience for new joiners.

Process-mining benefits (action)

A daily worklist of requests about to breach SLA [Service]: Every day, surface the open requests whose response or fulfillment target is closest to breaching, sorted by priority and time remaining, so the team saves the commitments that are still savable instead of finding out after the clock has run out.
Chase approvals that are sitting unactioned [Compliance]: Trigger a nudge when a request has been Waiting for Approval beyond your threshold with no decision recorded, so a pending sign-off gets chased rather than quietly holding up someone's access or equipment.
Alert on requests stuck waiting on the user [Efficiency]: Flag any request that has sat in Information Requested from User beyond a set time with no resume, so a ticket blocked on the requester gets a reminder instead of ageing off everyone's radar.
Step in when a request bounces between teams [Efficiency]: Flag any live request that has already been reassigned more than a set number of times so a coordinator can place it with the right group, before the requester experiences a third or fourth hand-off delay.
Push new-joiner onboarding requests that risk missing day one [Service]: Watch onboarding catalog requests against the joiner's start date and push the ones whose work orders are behind to the fulfillment teams early, so accounts and equipment are ready before the new hire walks in rather than after.
Review every reopened request the day it reopens [Service]: Route each request that flips from resolved back into fulfillment to a same-day review, so a botched provisioning gets proper attention immediately and you catch the pattern behind it early.

Data tables

SRM:Request - Service request master form (the request case table). One row per service request; carries the Request Number, status, priority, SRD, requester, assignment, and lifecycle timestamps.
SRM:WorkInfo - Service request work-info / activity log. Each entry is a timestamped note, status update, or communication against a request - the primary event source for mining the request flow.
WOI:WorkOrder - Fulfillment work order created to satisfy a service request. One or more work orders per request; carries its own status, assignment, and timestamps - the back-end vehicle for provisioning access and equipment.
AP:Signature - Approval signature records. One row per approval step in a request's approval chain - carries the approver, outcome, and decision timestamp; the source for approval-cycle-time and rejection analysis.
SRM:Request_AuditLog - Field-level audit history for service requests. One row per changed field with old value, new value, and timestamp - reconstructs status, approval, and assignment transitions.
TMS:Task - Fulfillment task under a work order (Task Management System). One row per task; the granular unit of provisioning work (create account, ship laptop) that drives work-order completion when its tasks close.
CTM:People - People master. Callers, submitters, and assignees referenced by incidents.
CTM:Support Group - Support group master. The groups incidents are assigned and reassigned to.
SRD:ServiceRequestDefinition - Service Request Definition (catalog item) master. Defines each offering in the service catalog - onboarding, software, access - from which requests are raised.

Service/Case Management (SERVICE)

Support tickets, SLAs, resolution

Activities

Create Case - New case record created on the Case record (com.bmc.dsm.case-lib:Case); Status = New, from Submit Date / first Case Activity entry.
Set Case Source - Source field set on Case (Agent, Email, Chat, Digital Workplace service request, Phone) - channel the case arrived on.
Categorize Case - Categorization fields set on Case (Category Tier 1/2/3) and Line of Business (Flowset) - classifies the case for the correct process.
Set Case Priority - Priority field set on Case (Critical, High, Medium, Low).
Apply Case Template - Case created from a Case Template - stamps default categorization, priority and the predefined task flow (Case Template reference record).
Assign Case - Status transition New -> Assigned on Case; Assignee and Assigned Group set (reference CTM:People, CTM:Support Group); assignment-change entry on Case Activity.
Reassign Case - Assignee or Assigned Group changed on an open case; assignment-change entry on Case Activity.
Start Working Case - Status transition Assigned -> In Progress on Case; status-change entry on Case Activity - the point the case SLA response target is met.
Add Activity Note - Activity note added on the Case Activity (Activity tab) - timestamped note with External Visibility Public or Internal; requires activity logging (default on).
Record Requester Response - Requester question/response captured as a Requester's Responses child record (populated from a Digital Workplace service request).
Generate Case Tasks - Case Task rows created in Staged status from the case's task flow / task templates when the case enters In Progress.
Assign Task - Task status Staged -> Assigned; Task Assignee / Assigned Group set (manual and external tasks require an assignee before proceeding).
Start Task - Task status Assigned -> In Progress on the Case Task record.
Set Task Pending - Task status In Progress -> Pending on the Case Task record (waiting on input).
Complete Task - Task status set to Completed on the Case Task record; task Actual End time recorded - the main per-step event stream for the case.
Bypass Task - Task status set to Bypassed on the Case Task record (task skipped in the flow).
Request Case Approval - Approval requested for the case; Case Approval record created in Pending (case-and-task approvals).
Approve Case - Case Approval Approval Status = Approved on the Case Approval record.
Reject Case Approval - Case Approval Approval Status = Rejected; Status transition to Approval Rejected on Case.
Set Case Pending - Status transition In Progress -> Pending on Case with a Status Reason (Customer Response, Third Party); pauses the resolution service target.
Resume Case - Status transition Pending -> In Progress on Case; status-change entry on Case Activity resumes the service target.
Resolve Case - Status transition to Resolved on Case; Resolution text and Actual Resolution Date recorded - the point the resolution service target is met.
Reopen Case - Status transition Resolved -> In Progress on Case (case reopened before close).
Send Resolution Survey - Survey issued on resolve for a Digital Workplace-sourced case; feedback returns as survey information viewable from the Case Activity.
Close Case - Status transition to Closed on Case; case closed (auto after the resolved period or set manually).
Cancel Case - Status transition to Canceled on Case; child Case Task rows are canceled with it.
Breach Service Target - A response or resolution Service Target Measurement for the case flips to Missed in Service Level Management (SLM) - a real measurement-status event.

Case attributes

Assigned Group (string) - Support group the case is assigned to; references CTM:Support Group.
Assignee (string) - Agent working the case; references CTM:People.
Case Type (string) - Type of case within the line of business.
Category Tier 1 (string) - Top-level categorization of the case.
Category Tier 2 (string) - Second-level categorization of the case.
Line of Business (string) - Flowset / line of business that owns the case process.
Resolution (string) - Resolution text recorded when the case is resolved.
Summary (string) - Short description of the case (Case Summary).
Case ID (string) - System-generated case display identifier (case id) on the Case record.
Company (string) - Customer company the case belongs to.
Customer (string) - Person the case is raised for (requester); references CTM:People.
Priority (string) - Handling priority of the case.
Source (string) - Channel the case was created through.
Status (string) - Case lifecycle state on the Case record.
Status Reason (string) - Qualifier for the current status (e.g. why the case is Pending or how it Resolved).
Actual Resolution Date (datetime) - Timestamp the case reached Resolved.
Closed Date (datetime) - Timestamp the case reached Closed.
Responded Date (datetime) - Timestamp the case was first moved to In Progress (response measurement).
Submit Date (datetime) - Timestamp the case was created (case start).
Target Date (datetime) - Service-target due date for the case (resolution SLA).

Process-mining benefits (historical)

Where cases stall between status changes [Efficiency]: See how long cases sit in each status - New, Assigned, In Progress, Pending - before they move on, and which lines of business and assigned groups are the slowest. The wait between reaching a status and leaving it becomes a counted, ranked bottleneck instead of a vague sense that some queues are always behind.
How much time cases lose in Pending [Service]: Measure how often cases drop into Pending waiting on the customer or a third party, how long each wait lasts, and which categories generate the most waiting. Time parked in Pending is time the requester is waiting, and the patterns show where a first response or a template is missing.
Cases that closed without the approval they needed [Compliance]: Check the cases whose type or line of business requires a case approval and surface the ones that reached Resolved or Closed without an approved approval record. This is the conformance evidence auditors ask for, built from your own case history rather than a sampled spot-check.
How often cases are reopened after being resolved [Efficiency]: Count the cases that moved to Resolved and then bounced back to In Progress on a reopen, and trace them to the groups, categories, and agents that produce them. Each reopen is a resolution that did not hold - rework you can target at its source.
Which service targets get missed, and where [Service]: Break your response and resolution service targets down by line of business, priority, and assigned group to see exactly where SLAs are missed rather than met. A cluster of misses on one team or one case type points at a staffing or routing problem you can fix.
Case tasks that drag out or get bypassed [Cost]: Compare how long each kind of case task takes from Assigned to Completed, and see which tasks are routinely bypassed or reassigned. You learn which steps in a case flow are chronically slow or skipped, so the task templates can be tightened or reordered.

Process-mining benefits (action)

A daily worklist of cases at risk of missing their target [Service]: Every day, surface the open cases whose resolution service target is close to its due date and still unresolved, sorted by how little time is left, so agents work the cases about to breach before the SLA is missed rather than after.
Chase cases stuck in Pending too long [Efficiency]: Trigger a notification when a case has sat in Pending beyond your threshold waiting on a customer or third party, so the agent nudges the requester or resumes the case instead of letting it quietly age past its target.
Flag unassigned or unacknowledged new cases [Service]: Produce a live list of cases still in New or Assigned that no agent has started working, sorted by age and priority, so nothing new sits untouched in a queue while its response clock runs.
Alert on case tasks blocking the case [Efficiency]: Watch cases in progress whose next case task has been sitting in Assigned or In Progress past its expected duration, and warn the case manager, so a single stuck task does not hold the whole case open.
Route pending approvals before they hold up delivery [Compliance]: Each day, surface the cases parked waiting on a case approval, sorted by how long the approval has been pending and the case target date, so approvers clear the sign-offs blocking imminent resolution instead of letting cases stall in Approval.
Review every reopened case the day it reopens [Service]: Route each case that moves from Resolved back to In Progress to an immediate review, so a resolution that failed gets fresh attention and the reason it did not hold is captured while the detail is current.

Data tables

BWF:Case - Core case record (the case table). One row per case; carries the Case ID, status, status reason, priority, categorization, line of business, customer, assignee/assigned group, and the submit/responded/resolution/closed timestamps.
BWF:Case Activity - Case activity / audit stream shown on the case Activity tab. One row per action - status changes, assignment changes, priority changes, and activity notes (Public or Internal) - the primary event source for reconstructing the case timeline. Requires activity logging (enabled by default).
BWF:Case Task - Case task record. Each row is a task within a case with its own status (Staged, Assigned, In Progress, Pending, Completed, Bypassed, Closed, Canceled), assignee, and start/end timestamps - the main per-step event stream for the case.
BWF:Case Approval - Approval records for case and task approvals. One row per approval request with its outcome - the source for approval-step timing and for the Approval Rejected status.
BWF:Requesters Responses - Requester's Responses child records - questions and responses shared by the people associated with a case, populated from Digital Workplace service requests. The source for requester-side communication on the case.
BWF:Service Target Measurement - Service Level Management measurement rows attached to a case or task. Each row is a response or resolution service target with its status (Attached / In Progress / Met / Missed) and due date - the source for SLA attainment and breach events.
BWF:Case Template - Case template definitions. Each row stamps default categorization, priority, and the predefined task flow onto new cases - the reference for expected task sequences and default handling.
CTM:People - People master. Callers, submitters, and assignees referenced by incidents.
CTM:Support Group - Support group master. The groups incidents are assigned and reassigned to.

Explore this interactively in the mindzie Knowledge Base.