The ServiceNow-Bamboo integration enables automated DevOps workflows by connecting Atlassian Bamboo's build and deployment pipeline with ServiceNow's change management and incident management processes. This integration solves the critical business problem of maintaining governance and visibility over CI/CD operations while ensuring rapid deployment cycles, primarily used by DevOps teams, release managers, and IT operations staff. The integration supports bi-directional data flows where Bamboo can trigger ServiceNow change requests for deployments, create incidents for build failures, and update CMDB configuration items with build artifacts, while ServiceNow can query Bamboo for build status and deployment information. The primary automation pattern uses Bamboo's REST API notifications and webhook capabilities combined with ServiceNow's RESTMessageV2 and Scripted REST APIs, residing primarily in the System Web Services and Integration modules.
Prerequisites
- •ServiceNow Paris or later instance with Integration Hub Professional license
- •Atlassian Bamboo Server or Data Center with administrator access
- •Bamboo REST API access with valid user account having build plan permissions
- •ServiceNow roles: admin, rest_service, web_service_admin, or integration_hub_action_designer
- •Network connectivity between ServiceNow instance and Bamboo server (MID Server if Bamboo is on-premise)
- •CMDB application and CI class structure configured in ServiceNow
- •Change Management plugin activated in ServiceNow instance
Architecture Overview
The ServiceNow-Bamboo integration uses RESTMessageV2 and Scripted REST APIs rather than a dedicated Integration Hub spoke, as no official Bamboo spoke exists in the ServiceNow Store. Authentication is established using Basic Authentication or API tokens stored in ServiceNow Connection & Credential Aliases under System Web Services > Outbound > REST Message. The data flow is primarily bi-directional with Bamboo pushing build status via webhooks to ServiceNow Scripted REST endpoints, while ServiceNow pulls build details and triggers deployments using outbound REST calls to Bamboo's REST API. A MID Server is required when Bamboo runs on-premise behind corporate firewalls, but cloud-hosted Bamboo instances can integrate directly. Rate limiting considerations include Bamboo's default 100 requests per minute per user limit and ServiceNow's standard API throttling, requiring proper error handling and retry logic in integration scripts.
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Implementation Steps
Create Bamboo API token and configure ServiceNow credentials
In Bamboo, navigate to your user profile > Personal access tokens and create a new token with 'Read' and 'Build' permissions for the plans you want to integrate. Copy the generated token as it won't be displayed again. In ServiceNow, navigate to Connections & Credentials > Credentials and create a new Basic Auth credential record with your Bamboo username and the API token as the password. Set the credential name to 'bamboo_api_credential' and ensure it's available for use in REST messages.
Create outbound REST message for Bamboo API calls
Navigate to System Web Services > Outbound > REST Message and create a new REST Message named 'Bamboo Integration'. Set the endpoint URL to your Bamboo base URL (e.g., https://bamboo.company.com). Configure the authentication type to use the credential created in step 1. Add authentication header by setting 'Use basic authentication' to true and reference the bamboo_api_credential. Test the connection by creating a test HTTP method pointing to '/rest/api/latest/info' to verify connectivity.
// Test method to verify Bamboo connectivity
var rm = new sn_ws.RESTMessageV2('Bamboo Integration', 'get');
rm.setStringParameterNoEscape('endpoint', 'https://bamboo.company.com/rest/api/latest/info');
var response = rm.execute();
gs.info('Bamboo connection test: ' + response.getStatusCode() + ' - ' + response.getBody());Configure REST message methods for build operations
Within the Bamboo Integration REST message, create multiple HTTP methods: 'getBuildStatus' (GET to /rest/api/latest/result/{planKey}-{buildNumber}), 'triggerBuild' (POST to /rest/api/latest/queue/{planKey}), and 'getDeploymentStatus' (GET to /rest/api/latest/deploy/project/{projectId}/environment/{environmentId}/results). Set appropriate HTTP headers including 'Accept: application/json' and 'Content-Type: application/json' for POST methods. Configure variable substitution for dynamic parameters like planKey, buildNumber, projectId, and environmentId using the ${variable_name} syntax in the endpoint URLs.
// Script to trigger a Bamboo build
function triggerBambooBuild(planKey, variables) {
var rm = new sn_ws.RESTMessageV2('Bamboo Integration', 'triggerBuild');
rm.setStringParameterNoEscape('planKey', planKey);
if (variables) {
rm.setRequestBody(JSON.stringify({variables: variables}));
}
var response = rm.execute();
return {
status: response.getStatusCode(),
body: JSON.parse(response.getBody())
};
}Create Scripted REST API for Bamboo webhooks
Navigate to System Web Services > Scripted Web Services > Scripted REST APIs and create a new API named 'Bamboo Webhook Handler'. Create a POST resource with the path '/bamboo/webhook/{event_type}' to handle different Bamboo events like build completion, deployment success, or build failure. Configure the resource to accept JSON payloads and implement proper authentication using API key validation or IP restriction. The script should parse the incoming webhook payload and determine the appropriate ServiceNow action based on the event type.
(function process(request, response) {
var eventType = request.pathParams.event_type;
var payload = request.body.dataString;
var bambooData = JSON.parse(payload);
switch(eventType) {
case 'build_complete':
handleBuildComplete(bambooData);
break;
case 'deployment_finished':
handleDeploymentFinished(bambooData);
break;
default:
gs.warn('Unknown Bamboo event type: ' + eventType);
}
response.setStatus(200);
response.setBody({status: 'processed'});
})(request, response);Implement change management integration logic
Create a Script Include named 'BambooChangeManager' to handle the creation and updates of change requests based on Bamboo deployment activities. This script should automatically create Normal or Emergency change requests when deployment plans are triggered, populate relevant fields like affected CIs, implementation plan, and approval requirements. Implement logic to update change request states based on deployment success or failure, and automatically close changes when deployments complete successfully. Include error handling for cases where CMDB CIs don't exist or change request creation fails.
var BambooChangeManager = Class.create();
BambooChangeManager.prototype = {
initialize: function() {},
createChangeForDeployment: function(deploymentData) {
var changeGR = new GlideRecord('change_request');
changeGR.initialize();
changeGR.short_description = 'Bamboo Deployment: ' + deploymentData.planName;
changeGR.description = 'Automated deployment from Bamboo plan: ' + deploymentData.planKey;
changeGR.type = 'normal';
changeGR.category = 'software';
changeGR.state = 'assess';
changeGR.u_bamboo_plan_key = deploymentData.planKey;
changeGR.u_bamboo_build_number = deploymentData.buildNumber;
var changeId = changeGR.insert();
return changeId;
},
type: 'BambooChangeManager'
};Configure incident creation for build failures
Implement automated incident creation logic within the Bamboo webhook handler to generate P3 incidents when builds fail. Create a dedicated assignment group for DevOps incidents and configure the incident categorization to reflect build/deployment issues. The incident should include relevant details from the Bamboo build failure such as error logs, failed test count, and build duration. Set up incident correlation rules to prevent duplicate incidents for the same failing build and implement auto-resolution when subsequent builds succeed.
function createIncidentForBuildFailure(buildData) {
var incidentGR = new GlideRecord('incident');
incidentGR.initialize();
incidentGR.short_description = 'Build Failure: ' + buildData.plan.shortName + ' #' + buildData.buildNumber;
incidentGR.description = 'Bamboo build failed with ' + buildData.failedTestCount + ' failed tests. Build duration: ' + buildData.buildDuration + 'ms';
incidentGR.urgency = '3';
incidentGR.impact = '3';
incidentGR.category = 'software';
incidentGR.subcategory = 'build failure';
incidentGR.assignment_group = 'devops_team';
incidentGR.u_bamboo_build_key = buildData.buildResultKey;
incidentGR.work_notes = 'Build log: ' + buildData.buildReason;
return incidentGR.insert();
}Set up CMDB artifact management
Create a scheduled job or event-driven process to update CMDB Configuration Items with build artifact information from Bamboo. Define a custom CI class or extend existing application CIs to include Bamboo-specific attributes like build number, deployment environment, artifact version, and build timestamp. Implement logic to create relationships between application CIs and infrastructure CIs affected by deployments. Configure the integration to maintain version history and deployment tracking across different environments (dev, staging, production).
function updateCMDBFromBamboo(deploymentData) {
var ciGR = new GlideRecord('cmdb_ci_appl');
ciGR.addQuery('u_bamboo_plan_key', deploymentData.planKey);
ciGR.query();
if (ciGR.next()) {
ciGR.u_current_version = deploymentData.version;
ciGR.u_last_deployment = new GlideDateTime();
ciGR.u_deployment_environment = deploymentData.environment;
ciGR.u_build_number = deploymentData.buildNumber;
ciGR.update();
// Create deployment relationship
var relGR = new GlideRecord('cmdb_rel_ci');
relGR.initialize();
relGR.parent = ciGR.sys_id;
relGR.child = deploymentData.targetServerId;
relGR.type = 'runs_on::runs';
relGR.insert();
}
}Test integration and configure monitoring
Create comprehensive test scenarios including successful builds, failed builds, deployment approvals, and rollback procedures to validate all integration touchpoints. Use ServiceNow's REST API Explorer to test outbound calls to Bamboo and verify webhook reception using the application logs. Set up monitoring dashboards to track integration health, including webhook delivery success rates, API call response times, and automated change request creation metrics. Configure email notifications for integration failures and establish procedures for manual intervention when automated processes fail.
// Integration health check script
var BambooHealthCheck = {
checkAPIConnectivity: function() {
try {
var rm = new sn_ws.RESTMessageV2('Bamboo Integration', 'getBuildStatus');
rm.setStringParameterNoEscape('planKey', 'SAMPLE-PLAN');
rm.setStringParameterNoEscape('buildNumber', '1');
var response = rm.execute();
return response.getStatusCode() < 500;
} catch (e) {
gs.error('Bamboo API health check failed: ' + e.message);
return false;
}
},
logHealthMetrics: function() {
var healthy = this.checkAPIConnectivity();
gs.info('Bamboo integration health: ' + (healthy ? 'UP' : 'DOWN'));
return healthy;
}
};Common Use Cases
Automated change request creation for production deployments
When Bamboo triggers a deployment plan targeting production environments, the integration automatically creates a change request in ServiceNow with pre-populated deployment details, affected CIs, and implementation timeline. The change request includes the build number, artifact versions, and rollback procedures extracted from Bamboo metadata. This ensures compliance with ITIL change management processes while maintaining deployment velocity, as the change can be pre-approved for standard deployments or routed for emergency approval based on deployment type and business rules.
Build failure incident management and escalation
Failed builds in critical Bamboo plans automatically generate incidents in ServiceNow with severity based on the affected application tier and failure type. The integration analyzes build logs, failed test counts, and historical failure patterns to determine appropriate assignment groups and escalation procedures. Incidents are automatically resolved when subsequent builds succeed, and recurring failures trigger problem records for root cause analysis, creating a closed-loop feedback system between development and operations teams.
CMDB synchronization with deployment artifacts
Each successful deployment updates corresponding CMDB configuration items with current software versions, deployment timestamps, and environment-specific metadata. The integration maintains deployment history across development, staging, and production environments, enabling accurate impact analysis and dependency mapping. Configuration items are automatically related to infrastructure components affected by deployments, providing real-time visibility into application topology and supporting more effective incident resolution and change impact assessment.
Release coordination with approval workflows
Major releases defined in Bamboo deployment projects trigger ServiceNow approval workflows involving business stakeholders, security teams, and operations managers. The integration creates structured approval tasks with embedded build information, test results, and deployment schedules, allowing approvers to make informed decisions without leaving ServiceNow. Approved deployments are automatically triggered back to Bamboo, while rejections pause the deployment pipeline and notify development teams of required changes or additional testing.
Compliance reporting and audit trail maintenance
All build and deployment activities are logged in ServiceNow with comprehensive audit trails linking code commits, build results, test outcomes, and production deployments to specific change requests and approval records. The integration generates compliance reports showing deployment frequency, success rates, rollback statistics, and approval compliance metrics required for SOX, HIPAA, or other regulatory frameworks. Historical data enables trend analysis and continuous improvement of deployment practices while maintaining complete traceability for audit purposes.
Troubleshooting
401 Unauthorized error when calling Bamboo REST API
First, verify that the API token is correctly stored in the ServiceNow credential record and hasn't expired in Bamboo. Check the Bamboo user account permissions to ensure it has access to the specific build plans being called. Navigate to System Logs > System Log > All to examine detailed error messages, and test the credential manually using a REST client like Postman with the same authentication headers. If the token is valid, verify that the Bamboo user account hasn't been locked or disabled due to failed authentication attempts.
Webhook payloads received but no ServiceNow records created
Check the ServiceNow application logs under System Logs > All to identify any JavaScript errors in the Scripted REST API handler. Verify that the webhook URL in Bamboo exactly matches the ServiceNow Scripted REST API endpoint including the correct event_type parameter. Use gs.info() statements in the webhook handler to log received payloads and confirm data parsing is working correctly. Common issues include JSON parsing errors due to unexpected payload structure or missing field validation causing record insertion failures.
MID Server timeout errors on outbound Bamboo calls
Navigate to MID Server > Servers and check the status and logs of the MID Server handling Bamboo integration traffic. Increase the socket timeout values in the REST Message configuration under the Advanced tab to accommodate slower Bamboo responses during build operations. Verify network connectivity between the MID Server and Bamboo server, including firewall rules and proxy configurations. Consider implementing retry logic with exponential backoff in integration scripts to handle transient network issues and Bamboo server load.
Duplicate change requests created for same deployment
Implement correlation logic in the change request creation script using Bamboo's unique build result key or plan execution ID as a correlation field. Add a before-insert business rule on change requests to check for existing records with the same Bamboo identifiers. Configure Bamboo webhooks to use delivery guarantees and idempotent processing to handle webhook retries without creating duplicate records. Review the deployment trigger configuration in Bamboo to ensure webhooks aren't being sent multiple times for the same deployment event.
CMDB CI updates failing with field validation errors
Check the target CI class dictionary to ensure all Bamboo-specific fields exist and have appropriate data types and lengths configured. Use try-catch blocks around CI update operations and log specific validation errors to identify field constraint violations. Verify that referenced fields like assignment groups, locations, or related CIs exist in ServiceNow before attempting updates. Implement field mapping validation to ensure Bamboo data types match ServiceNow field requirements, particularly for date fields and choice lists.
Integration performance degradation with high build volume
Implement asynchronous processing for webhook handlers using Business Rule async execution or Event-driven processing to prevent timeout issues during peak build periods. Configure connection pooling and persistent HTTP connections in REST Message configuration to reduce connection overhead. Add indexing to custom Bamboo correlation fields in change requests and CMDB tables to improve query performance. Consider implementing batch processing for CMDB updates and rate limiting for outbound API calls to prevent overwhelming either system during high-volume deployment windows.
Pro Tips
- →Configure Bamboo plan variables as ServiceNow system properties to enable dynamic integration behavior without code changes, such as automatically switching between emergency and normal change request types based on deployment urgency flags set in Bamboo deployment environments.
- →Implement a circuit breaker pattern in your integration scripts to automatically disable webhook processing when ServiceNow experiences high load, preventing cascade failures and allowing manual override when needed for critical deployments.
- →Use ServiceNow's Transform Maps with field mapping to standardize Bamboo webhook data before processing, enabling easier maintenance when Bamboo payload formats change and providing data validation at the integration boundary.
- →Create custom ServiceNow metrics and KPIs to track integration health, including webhook delivery success rates, API response times, and automated process completion rates, then configure automated alerting when thresholds are exceeded.
- →Leverage ServiceNow's Flow Designer to create visual workflow processes that handle complex deployment approval scenarios, making it easier for non-technical stakeholders to understand and modify approval routing based on application criticality and deployment risk.
Known Limitations
- —Bamboo's REST API has a default rate limit of 100 requests per minute per user, which can be restrictive in high-volume CI/CD environments with multiple concurrent builds and deployments. This limitation requires careful implementation of request queuing and retry logic to prevent integration failures during peak activity periods.
- —The integration relies on webhook delivery reliability between Bamboo and ServiceNow, which can be affected by network connectivity issues or ServiceNow maintenance windows, potentially causing missed build status updates or deployment notifications. Manual reconciliation processes may be needed to handle webhook delivery failures.
- —Bamboo's webhook payload structure varies between different plan types and configurations, requiring robust error handling and data validation to prevent integration failures when new plan types are introduced or existing plans are reconfigured by development teams.
- —ServiceNow's 24-hour limit on Scripted REST API execution time can cause issues with long-running deployment processes that require extended monitoring or approval workflows, necessitating alternative approaches like scheduled jobs or event-driven processing for complex scenarios.
- —The integration cannot access Bamboo's detailed build logs or artifact contents through the REST API, limiting the depth of diagnostic information available in ServiceNow incidents and change requests, which may require additional file-based integrations or log aggregation solutions.
Frequently Asked Questions
Can this integration handle Bamboo Cloud hosted on Atlassian's infrastructure?
Yes, the integration works with both Bamboo Server/Data Center and Bamboo Cloud instances, though authentication methods differ slightly. Bamboo Cloud uses Atlassian API tokens that can be generated from your Atlassian account settings, while on-premise Bamboo typically uses HTTP Basic Authentication or personal access tokens. The REST API endpoints and webhook configurations are identical, but you'll need to adjust the base URL to point to your Atlassian Cloud instance (e.g., company.atlassian.net).
How do I handle Bamboo deployment approvals that require ServiceNow approval workflows?
Configure Bamboo deployment environments with manual stages that pause execution until external approval is received, then use ServiceNow approval workflows to generate approval tasks for stakeholders. When approvals are complete, ServiceNow can automatically call Bamboo's REST API to continue or cancel the deployment using the queue continuation endpoints. This requires configuring webhook callbacks from ServiceNow to Bamboo and implementing proper approval state synchronization between both systems.
What happens if ServiceNow is down during a critical Bamboo deployment?
Bamboo deployments will continue to execute based on their configured automation, but integration touchpoints like change request updates and incident creation will fail. Implement error handling in Bamboo notification configurations to log failed webhook deliveries, and consider setting up alternative notification channels like email or Slack for critical deployment notifications. After ServiceNow recovery, run reconciliation scripts to synchronize missed deployment data and manually create any required change requests or incidents.
Can I integrate multiple Bamboo instances with a single ServiceNow instance?
Yes, you can integrate multiple Bamboo instances by creating separate REST Message configurations with unique names and credential sets for each Bamboo environment. Use instance identifier prefixes in correlation fields and configure separate Scripted REST API endpoints or add instance identification logic in webhook handlers to route data appropriately. This approach is commonly used for organizations with separate Bamboo instances for different business units or geographic regions.
How do I prevent sensitive build information from appearing in ServiceNow records?
Implement data sanitization in webhook handlers and outbound API response processing to filter sensitive information like passwords, API keys, or proprietary code references before creating ServiceNow records. Configure Bamboo plan variables carefully to avoid including sensitive data in build metadata, and use ServiceNow's encryption at rest features for storing sensitive integration data. Consider implementing field-level access controls on custom Bamboo integration fields to restrict visibility to authorized personnel only.
What's the best approach for testing this integration in development environments?
Set up parallel integration configurations pointing to development instances of both Bamboo and ServiceNow, using separate credential sets and webhook endpoints to prevent cross-environment data contamination. Use Bamboo's plan cloning features to create test plans that mirror production configurations but deploy to development targets. Implement feature flags or system properties in ServiceNow integration scripts to enable testing modes that log actions without creating actual records, allowing safe integration testing in production environments.
Does this integration support Bamboo's Elastic Bamboo agents?
The integration works transparently with Elastic Bamboo agents since it operates through Bamboo's server-side REST APIs and webhooks rather than direct agent communication. Build results, deployment status, and plan execution data are available through the standard Bamboo REST endpoints regardless of whether builds execute on local or elastic agents. However, agent-specific performance metrics and resource utilization data may require additional API calls to Bamboo's resource monitoring endpoints for comprehensive CI/CD pipeline visibility in ServiceNow.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue