Managing Business and Technical Services, along with their offerings, within ServiceNow can be a significant hurdle for many organizations. Often, Service/Portfolio Owners aren't fully versed in the nuances of the Common Service Data Model (CSDM), and Configuration Management teams are understandably hesitant to grant direct access to the these tables.
Traditionally, this led to a cumbersome process: Service/Portfolio owners would compile service details and relay them to the Config team, often via service requests or clunky Excel attachments, for manual updates in the CMDB later done by the platform admin teams. This created bottlenecks and inefficiencies.
Service Builder has emerged as a powerful solution to this challenge. It provides a user-friendly interface that empowers Service Owners to manage their services directly, while still giving the Configuration Management team peace of mind through built-in approval mechanisms.
While ServiceNow's product documentation offers a solid foundation, this article dives into additional insights and practical tips to help organizations to effectively set up Service Builder and drive its wider adoption across the organization.
1. Prerequisite: Aligning with the CSDM Service Classes
It's vital to understand that services created via Service Builder are designed to reside in specific CSDM service class tables: Business Services in cmdb_ci_service_business and Technical Services in cmdb_ci_service_technical.
If the organization currently manages its services primarily within the generic cmdb_ci_service table, now is the opportune time to classify and migrate them to their respective dedicated classes. This alignment is crucial not only for Service Builder but also for other products.
2. Extending Service Builder for Additional Fields
Service Builder comes equipped with a comprehensive set of standard fields, usually more than sufficient for out-of-the-box service record management. However, specific business requirements often necessitate custom attributes, some of which might even be mandatory for service creation.
Service Builder is built on top of ServiceNow's Catalog Wizard and Composite Record Producer (CRP) framework. Here's how those essential extra fields can be added:
Step 1: Add the Variable to the Composite Record Producer
- Navigate to "Composite Record Producers" in the Application Navigator.
- Select the CRP that needs to be modified:
- "Create Business Service CRP" for Business Services.
- "Create Technical Service CRP" for Technical Services.
- Scroll to the "Variables" related list and click "New".
- Fill in the variable details, carefully mapping it to the required field on the target CMDB table. For example, there is a requirement to capture the "Managed By Group."
- Submit the record.
Step 2: Display the Variable on the Service Builder Wizard Step
The next step is to make the newly created variable visible and editable within the Service Builder interface.
- Navigate to "Maintain Wizards" in the Application Navigator.
- Select the wizard the requires modification:
- "Create Business Service" for Business Services.
- "Create Technical Service" for Technical Services.
- Choose the specific step where new information has to be captured. In this "Managed By Group" example, the "Team" step, would be a fitting location. (There could be scenarios where a new Step has to be created)
- Each step is further divided into Sections. Choose the appropriate section the variable should be displayed. In this example the "Core Service Team" Section would be an appropriate place for the displaying the question. (There could be scenarios where a new section has to be created)
- Click "New" within Catalog Wizard Questions.
- Fill in the details, by providing choosing the question and the ordering to ensure it appears logically on the form and Submit the form.
- The new variable should now be available within Service Builder, ready for the Service/Portfolio Owners to populate!
3. Enhancing User Guidance with Catalog Wizard Feedback
A common challenge for users is understanding the nuances of each field (e.g., the difference between "Managed by" and "Owned By"). While tooltips offer some help, providing broader contextual information can significantly improve data accuracy.
Leverage the "Catalog Wizard Feedback" feature to offer general guidance to users:
- Navigate to "Maintain Wizards" again and select the target wizard.
- Within each step contains the "Catalog Wizard Feedback" reference field.
- Modify these details to align with the organization's specific terminology and data requirements.
This feedback will display prominently on the side of the Service Builder interface for the corresponding step, guiding users to provide the most accurate information.
4. Customizing the Approval Flow
ServiceNow provides a standard approval flow for service publishing, which serves as an excellent starting point. The documentation can be found here.
This standard flow is managed by an Out-of-the-Box (OOB) subflow named "Publish Service Approval subflow." If this doesn't perfectly align with the organization's requirements (e.g., needing additional approval layers or different approval criteria), the subflow can be configured within Flow Designer to meet the exact needs.
5. Important Considerations for Service Builder Implementation
As Service Builder is being rolled out, keep these critical points in mind:
- Service State Model: Services managed through Service Builder adhere to a specific state model: Draft, Awaiting Approval, and Published. It's important to note that a "Published" state in Service Builder does not equate to the service being "operational." Also, if a service record is created directly in the Core UI, its state field will typically be empty. Be mindful of these differences while configuring any reference qualifiers or automations that depend on the state field.
- Draft Service Records: When a service is being edited in Service Builder, a new temporary service record is created with a name of "[Draft] Service Name" and State "Draft" This allows the existing, operational service record to remain unchanged while modifications and approvals are in progress. Once the service is published, this draft record is automatically deleted and the original Service record is updated. The active field for draft records is set to false to prevent them from appearing in search results. However, be aware of their existence when building reference qualifiers, running automations on the service table, or during testing as there would be 2 records for the same service (one in published and active and other in draft and inactive).
Conclusion: A Win-Win for Service Management
Service Builder is a remarkable tool that empowers Service Owners to take ownership of their services and offerings with minimal support from Configuration Management and Admin teams. It not only frees up valuable time for Configuration teams but also provides them with crucial visibility and control over data integrity. For administrators, it automates what was once a manual, time-consuming process, allowing them to focus on more productive activities.
By understanding its underlying mechanisms and applying these practical tips, the organization can fully embrace Service Builder and transform its service management capabilities.
