.png)
BMC Helix Integration Guide
Integrate BMC Helix service-management data with enterprise applications through REST APIs, selected callbacks, attachment APIs, and orchestrated workflows.
BMC Helix integration options at a glance
BMC Helix primarily supports REST API integrations for creating, retrieving, updating, and deleting service-management objects such as Incidents, Work Orders, Change Requests, Persons, and Configuration Items. Selected Helix products and use cases provide event notifications or outbound callbacks, while scheduled REST polling is available when a required event is not exposed. Attachment APIs support files associated with eligible records. Authentication is service-specific and may use OAuth 2.0, bearer tokens, users, or API tokens. Martini can consume these APIs, receive documented callbacks, expose normalized REST APIs, transform payloads, apply validation and routing rules, and manage retries and synchronization state.
| Integration point | Supported by BMC Helix? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Create, retrieve, update, and delete Incidents, Work Orders, Change Requests, Persons, Configuration Items, and related service-management data. Exact resources vary by Helix product and release. | Martini can consume BMC Helix REST APIs from workflows, map request and response payloads, apply validation and business rules, and expose normalized APIs for other applications. |
| Webhooks and outbound callbacks | Limited | Selected Helix products and use cases can provide event notifications or outbound integration callbacks for record or status changes. | Martini can expose an API endpoint to receive documented callbacks, validate and deduplicate notifications, and invoke downstream workflows. Scheduled polling can cover events without a callback. |
| SOAP APIs | Legacy | SOAP or web-service interfaces may remain available in parts of the broader BMC product ecosystem or service-specific deployments. | Martini can consume a documented BMC SOAP endpoint where a supported WSDL and service are available, while treating SOAP as a service-specific legacy option. |
| Bulk, asynchronous, and batch APIs | Limited | Batch behavior, asynchronous jobs, pagination, and bulk operations may be available for selected Helix services and resources. | Martini can orchestrate pages or batches, track asynchronous results where documented, control concurrency, and retry transient failures after confirming the target API behavior. |
| File and attachment APIs | Yes | Transfer attachments associated with selected Incidents, Work Orders, forms, and other eligible parent records. | Martini can coordinate the parent record and attachment requests, transform metadata and content, and route large-file or permission failures separately from the main transaction. |
| Authentication | Yes | Service-specific API access can use OAuth 2.0, bearer access tokens, users, or API tokens, with permissions controlled by tenant and application roles. | Martini can use environment-managed authentication configuration and secrets, send bearer credentials securely, and separate tenant URLs, client details, and scopes from workflow logic. |
| Direct database access | No | Direct access to BMC Helix SaaS tenant databases is not a standard integration method. Supported APIs, exports, reporting interfaces, and event mechanisms are preferred. | Martini should integrate through supported BMC Helix APIs and documented endpoints rather than relying on direct tenant database connectivity. |
How BMC Helix exposes data and business events
BMC Helix REST APIs
REST is BMC Helix's primary API-based integration mechanism. BMC Helix ITSM and related services expose resources for service-management records and platform operations, although resource names, fields, and endpoint behavior vary by product and release.
Martini implementation pattern
Martini implementation pattern: a workflow receives an API request, schedule, or external event, authenticates to the relevant BMC Helix service, retrieves or submits the required resource, maps the response to a canonical model, and writes the result to downstream systems. Martini can also expose a normalized API that hides Helix-specific forms, fields, and authentication details.
Implementation sequence
BMC Helix callbacks and notifications
BMC Helix products support selected notification, event, and outbound integration patterns, but callback coverage is product-, object-, and use-case-specific. Universal webhook coverage for every object should not be assumed.
Martini implementation pattern
Martini implementation pattern: Martini exposes a controlled API endpoint for a documented BMC Helix callback, validates the notification, retrieves the current resource when necessary, and applies idempotency and ordering rules. When the required callback is unavailable, a scheduled workflow polls the REST API using a timestamp, record identifier, status, or synchronization marker.
Implementation sequence
BMC Helix SOAP services
SOAP and web-service interfaces exist in parts of the broader BMC product ecosystem and may be available for specific deployments or legacy integrations. Coverage for new BMC Helix integrations is service-specific.
Martini implementation pattern
Martini implementation pattern: where BMC provides a supported WSDL and SOAP endpoint, Martini consumes the service, manages service-specific authentication, transforms XML messages into the integration model, and routes SOAP faults or transport failures through workflow error handling.
Implementation sequence
BMC Helix attachment APIs
BMC Helix supports attachment operations for selected records and forms. Attachments are associated with a parent object such as an Incident or Work Order and remain subject to API permissions, file limits, and product-specific behavior.
Martini implementation pattern
Martini implementation pattern: the workflow creates or identifies the parent BMC Helix object, transfers attachment metadata and content through the applicable API, and records the relationship between source file, parent identifier, and target attachment. Large files and upload errors can be handled as separate workflow branches.
Implementation sequence
Common BMC Helix integration patterns
Pattern 1: Synchronize Salesforce Cases with BMC Helix Incidents
When to use this pattern
Use this pattern when customer-facing Cases require internal service or operations handling in BMC Helix. The integration can create an Incident from a qualifying Case and return assignment, status, and resolution information to Salesforce.
Integration direction
Example Mapping
| BMC Helix Field | Canonical Field | Target Field |
|---|---|---|
| Case.Id | sourceCaseId | externalCorrelationId |
| Case.Subject | summary | Incident description or summary |
| Case.Priority | priority | Incident impact and urgency |
| Case.Status | lifecycleStatus | Incident status |
Martini implementation pattern
Martini receives a Salesforce event or polls for changed Cases, validates required customer and service data, looks up an existing Incident by correlation ID, and creates or updates the BMC Helix Incident. A reverse workflow maps Incident status, assignment, and resolution details back to Salesforce. Retry policies distinguish throttling and network failures from validation or authorization errors.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- idempotency
- error handling
Pattern 2: Coordinate BMC Helix Change Requests with Jira Software issues
When to use this pattern
Use this pattern when infrastructure or service Changes require software-development work, deployment activity, or implementation evidence in Jira Software. It supports controlled synchronization rather than assuming identical lifecycles.
Integration direction
Example Mapping
| BMC Helix Field | Canonical Field | Target Field |
|---|---|---|
| Change Request number | changeId | Jira issue key or external reference |
| Approval status | approvalState | Jira workflow status |
| Planned start and end | implementationWindow | Jira planned dates |
| Implementation status | executionStatus | Jira issue status |
Martini implementation pattern
A Martini workflow retrieves qualifying Change Requests, maps approvals, dates, environments, and implementation details into Jira Software, and stores both identifiers. Updates from Jira are validated against allowed BMC Helix lifecycle transitions before being submitted. Conflicting changes are routed for review instead of blindly overwriting either system.
Martini capabilities used
- workflow orchestration
- REST API consumption
- data mapping
- validation
- conditional routing
- error handling
Pattern 3: Synchronize Workday employees to BMC Helix Persons
When to use this pattern
Use this pattern when BMC Helix Person records must reflect employee, manager, department, location, and employment-status data from Workday. It is suitable for scheduled incremental synchronization or an initial population.
Integration direction
Example Mapping
| BMC Helix Field | Canonical Field | Target Field |
|---|---|---|
| Workday worker ID | employeeIdentifier | Person source identifier |
| Worker name | displayName | Person name |
| Supervisory organization | department | Person department |
| Worker status | employmentStatus | Person status |
Martini implementation pattern
A scheduled Martini workflow retrieves changed Workday data through a supported API or export, normalizes organizational values, and upserts Persons using a stable employee identifier. It handles inactive employees, rehires, missing managers, and duplicate prevention, while persisting a synchronization watermark for the next run.
Martini capabilities used
- scheduled workflows
- API or file consumption
- data transformation
- upsert logic
- validation
- checkpoint management
Pattern 4: Route BMC Helix Incident alerts to collaboration channels
When to use this pattern
Use this pattern when operations teams need timely notifications for high-priority Incidents or status changes in Microsoft Teams or Slack. It avoids duplicate messages and can publish a resolution update.
Integration direction
Example Mapping
| BMC Helix Field | Canonical Field | Target Field |
|---|---|---|
| Incident number | incidentKey | Notification correlation key |
| Priority and impact | severity | Message severity |
| Assigned group | assignmentGroup | Channel routing |
| Status and resolution | lifecycleUpdate | Message content |
Martini implementation pattern
Martini receives a documented BMC Helix notification or runs a scheduled query, filters Incidents by priority, impact, service, or assignment group, and formats a collaboration message. A stable notification key prevents duplicate posts, while transient delivery failures are retried and failed messages are retained for operational review.
Martini capabilities used
- event-driven workflows
- scheduled synchronization
- business rules
- data mapping
- deduplication
- retry handling
Applications commonly integrated with BMC Helix
BMC Helix can be connected with customer-service, development, collaboration, workforce, and enterprise business applications. The exact direction and object coverage depend on the BMC Helix product, tenant configuration, and APIs enabled in the connected application.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize customer Cases with BMC Helix Incidents and return service status, assignment, and resolution information. | Salesforce → Martini → BMC Helix | Martini consumes Salesforce events or scheduled data, correlates Cases with BMC Helix Incidents, maps customer and service fields, and applies idempotent create-or-update logic in both directions. |
| ServiceNow | Coordinate or migrate Incidents, Change Requests, and Configuration Items during platform coexistence or service-management consolidation. | ServiceNow → Martini → BMC Helix | Martini orchestrates API-based migration or bidirectional synchronization, maps lifecycle and priority values explicitly, preserves source identifiers, and routes conflicts for review. |
| Jira Software | Connect BMC Helix Change Requests and operational Incidents with software-development work and implementation status. | BMC Helix → Martini → Jira Software | A Martini workflow maps Change Request identifiers, approvals, planned dates, environments, and implementation status to Jira Software issues, then applies controlled updates back to BMC Helix. |
| Microsoft Teams | Notify service and operations teams about high-priority Incidents, Changes, approvals, and resolution updates. | BMC Helix → Martini → Microsoft Teams | Martini receives a documented BMC Helix notification or polls for qualifying changes, filters by priority or assignment group, formats a Teams message, and uses a stable notification key to prevent duplicates. |
| Slack | Distribute operational alerts and Incident updates to engineering and service channels. | BMC Helix → Martini → Slack | Martini retrieves or receives selected BMC Helix Incident changes, applies routing rules, transforms them into Slack-compatible messages, and records notification state for retry and deduplication. |
| Workday | Keep BMC Helix Person records aligned with employee, department, manager, location, and employment-status data. | Workday → Martini → BMC Helix | Martini consumes a supported Workday API or export, normalizes organizational values, upserts Person records using a stable employee identifier, and handles inactive employees and rehires. |
| SAP S/4HANA | Associate service Incidents and Changes with business processes, assets, or operational information managed in SAP. | SAP S/4HANA → Martini → BMC Helix | Martini coordinates the relevant SAP and BMC Helix APIs, translates identifiers and lifecycle values, validates relationships such as Configuration Items, and records failed transactions for replay. |
| NetSuite | Connect service issues, customer information, or asset-related data with business and finance operations. | NetSuite → Martini → BMC Helix | Martini retrieves selected NetSuite objects, maps them to BMC Helix service-management fields, applies business rules for correlation and ownership, and updates both systems where required. |
How to build a BMC Helix integration in Martini
Objective
Establish the BMC Helix tenant and service connection with the authentication method required by the target product, such as OAuth 2.0, bearer tokens, users, or API tokens.
Instructions in Martini
- Confirm the exact BMC Helix product and API scope
- Store tenant URLs, client details, tokens, and secrets in environment configuration
- Configure HTTPS and the required roles, permissions, and tenant access
- Test access against the specific REST or SOAP service
Objective
Select an event, callback, API request, or scheduled trigger based on the availability of the required BMC Helix event and the synchronization latency needed.
Instructions in Martini
- Use a documented callback when the required event is supported
- Expose a Martini API endpoint for inbound notifications
- Use a scheduler when callback coverage is unavailable
- Define the synchronization watermark or correlation key
Objective
Retrieve the current BMC Helix resource or accept the inbound payload, accounting for pagination, related objects, attachments, and records modified during a synchronization run.
Instructions in Martini
- Retrieve all required pages from list or search operations
- Fetch related Persons, Configuration Items, or attachments when needed
- Use modified timestamps, IDs, or status filters for incremental retrieval
- Preserve source identifiers and event metadata
Objective
Coordinate the BMC Helix call, external application calls, branching, state management, and response behavior in a reusable Martini workflow.
Instructions in Martini
- Separate validation, lookup, transformation, and write stages
- Apply conditional routing for product, status, priority, or assignment group
- Use correlation IDs across every external call
- Return a controlled API response or persist the processing result
Objective
Transform BMC Helix forms, entries, and business-oriented resources into the target application's model while validating required fields and tenant-specific customizations.
Instructions in Martini
- Map Incidents, Work Orders, Change Requests, Persons, or Configuration Items explicitly
- Translate status, priority, impact, urgency, and approval values
- Validate required fields before submission
- Handle custom fields as versioned integration contracts
Objective
Create or update the downstream object and, where required, submit the resulting change back to BMC Helix without creating loops or duplicates.
Instructions in Martini
- Look up existing objects using stable external identifiers
- Apply idempotent create-or-update logic
- Create parent records before attachments or related objects
- Prevent circular updates with source and correlation metadata
Common BMC Helix data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Incident | Represent a service disruption or support issue, including priority, impact, assignment, status, and resolution information. | Salesforce, ServiceNow, Microsoft Teams, Slack, Jira Software | Martini retrieves or receives Incident changes, maps lifecycle and priority values, correlates external identifiers, and performs idempotent create-or-update operations. |
| Work Order | Track planned or assigned operational work associated with service delivery or fulfillment. | ServiceNow, SAP S/4HANA, Salesforce, collaboration applications | Martini validates required fields and related Persons or Configuration Items, transforms dates and statuses, and submits or synchronizes Work Orders through the applicable API. |
| Change Request | Manage planned changes, approvals, implementation details, and change lifecycle status. | Jira Software, ServiceNow, Microsoft Teams, SAP S/4HANA | Martini maps approvals, planned dates, environments, identifiers, and implementation status while applying conflict and retry rules. |
| Problem Investigation | Analyze recurring or underlying causes associated with Incidents and service quality issues. | ServiceNow, Jira Software, knowledge and collaboration applications | Martini synchronizes selected investigation details, preserves correlation to Incidents, and routes updates according to status and ownership rules. |
| Person | Represent employees, support users, customers, managers, departments, and related organizational information. | Workday, Salesforce, ServiceNow, Microsoft Entra ID | Martini consumes source employee data, normalizes organizational fields, upserts using a stable identifier, and handles inactive or reactivated people. |
| Configuration Item | Represent infrastructure, applications, services, or other managed assets associated with service records. | BMC Helix Discovery, ServiceNow, SAP S/4HANA, asset repositories | Martini preserves source identifiers and relationships, validates referenced Configuration Items before record creation, and handles tenant-specific fields conservatively. |
Authentication and security considerations
Service-specific authentication
BMC Helix authentication depends on the product and API. OAuth 2.0, bearer access tokens, users, or API tokens may be available, but the grant, scopes, token endpoint, and permissions must be confirmed for the target service.
Tenant and role boundaries
Access is governed by tenant configuration, BMC Helix roles, application permissions, and record-level authorization. A valid token does not necessarily grant access to every form, object, or operation.
Martini configuration
- Use HTTPS for API traffic.
- Store client secrets, tokens, tenant identifiers, and base URLs in Martini secrets or environment configuration.
- Use least-privilege service accounts and separate credentials by environment.
- Log correlation identifiers and outcomes without exposing credentials or sensitive payload content.
Operational considerations for BMC Helix integrations
API behavior
- Confirm product scope, endpoint versions, pagination behavior, request limits, and available resources for the specific Helix service.
- Use controlled concurrency and backoff for throttling or transient failures.
- Retrieve all pages and account for records modified during a synchronization run.
Data integrity
- Use stable external identifiers or correlation fields to prevent duplicate Incidents, Work Orders, and other objects.
- Map statuses, priorities, impact, urgency, and approvals explicitly rather than assuming values are interchangeable.
- Create related Persons and Configuration Items in the correct order and preserve relationships.
Change and testing management
- Treat custom fields, forms, workflows, and schemas as tenant-specific integration contracts.
- Test authentication, validation failures, retries, pagination, attachment limits, and out-of-order updates.
- Monitor workflow outcomes and retain enough correlation data to replay failed transactions safely.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration instead of isolated scripts
Martini provides a governed workflow layer for calling BMC Helix and other enterprise systems, applying business rules, transforming payloads, and handling responses consistently. This avoids duplicating authentication, pagination, validation, and retry logic across individual scripts.
Reusable integration assets
Teams can expose a normalized API, reuse workflow logic, and separate tenant configuration from implementation behavior. This helps downstream applications avoid coupling directly to BMC Helix forms, fields, endpoint versions, or authentication details.
Operational control
- Centralize correlation, error handling, retry, and monitoring behavior.
- Support event-driven, scheduled, API-led, and batch-oriented integration patterns.
- Apply explicit mappings and validation when BMC Helix lifecycles differ from external systems.
Frequently asked questions
BMC Helix is primarily integrated through REST APIs for service-management and platform operations. Selected products and use cases also provide event notifications or outbound callbacks, while scheduled API polling can cover events that are not exposed. Attachment APIs support files associated with eligible records, and service-specific authentication may use OAuth 2.0, bearer tokens, users, or API tokens.
Yes. Martini can consume BMC Helix REST APIs, receive documented callbacks or notifications through a Martini API, consume a supported SOAP service where required, transform BMC Helix objects, and orchestrate synchronization with other enterprise applications.
No. A dedicated BMC Helix connector is not required. Martini can use BMC Helix's confirmed native integration mechanisms, including REST APIs, service-specific authentication, selected callbacks or notifications, attachment APIs, and supported SOAP services where applicable.
Lonti does not charge an additional per-connector or per-vendor fee to integrate BMC Helix. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from BMC, cloud infrastructure, or other third-party systems depending on subscriptions, API usage, and deployment model.
REST APIs are the primary choice for current BMC Helix integrations. Use documented callbacks or notifications when the required product and event support them, scheduled polling when they do not, and attachment APIs for files associated with eligible records. SOAP should be treated as a legacy or service-specific option, and GraphQL should not be assumed to provide general access to BMC Helix ITSM objects.
No. Event, notification, and callback coverage is product-, object-, and use-case-specific. A required event such as Incident creation, status change, Change approval, or Work Order completion should be verified individually. When a callback is unavailable, Martini can poll the relevant REST API using a timestamp, identifier, status, or synchronization marker.
Martini can retrieve or receive BMC Helix objects, map them to a canonical or target-system model, translate statuses and priorities, validate relationships, and apply business rules before writing the result. Scheduled workflows can use modified timestamps, record identifiers, or persisted cursors for incremental synchronization, while correlation IDs support idempotent updates.
Martini can classify authentication, authorization, validation, throttling, timeout, not-found, attachment, and endpoint errors. Transient failures can use controlled retries and backoff, while permanent failures are routed for review. Stable external identifiers, lookup-before-create logic, correlation IDs, and notification keys help prevent duplicate records and messages.
Yes. Martini can expose a normalized REST API that hides BMC Helix-specific forms, fields, tenant details, authentication configuration, and version differences from consuming applications. Workflows behind the API can validate requests, invoke BMC Helix REST services, apply business rules, and return a controlled response.
Related Martini documentation
API Integration
Data and Security
Integrate BMC Helix with Martini
Connect BMC Helix to enterprise applications through governed APIs and workflows that manage authentication, transformation, synchronization, business rules, and operational resilience.