Configuration and Implementation of Incident,Problem and Change Management modules in relation to MSP.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-15-2018 04:46 AM
Hi All,
Can anyone share some inputs on what are the configuration and implementation practices to be taken or considered for Incident,Problem and Change Management Modules with relation to MSP.
Regards,
Gourav

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-15-2018 05:16 AM
Hi Gourav,
I highly recommend attending the Domain Separation class to get the foundations of process and data visibility and that will answer most of your questions. The other advantage of taking a course is that you can ask specific questions to the instructor even if it's an online course.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-15-2018 06:25 AM
Gourav,
I'd second Chuck's recommendation to attend the Domain Separation course. Below, I've included an excerpt from the course syllabus for your reference. The course concentrates on common domain separation use cases for MSPs and labs are based on implementation experience from dozens of domain-separation experts with an average of 8-9+ years of experience with ServiceNow implementing and running ServiceNow within MSPs.
I think the course will be very useful for you.
Module 1 defines Domain Separation and enables students to evaluate whether domain separation is warranted through investigating several use cases. You learn when to use Domain Separation, who uses Domain Separation, and possible alternatives.
Module 2 explains the key concepts behind Domain Separation and its impact on data visibility, process applicability, and user interface. Emphasis is placed on exploring the hierarchical relationships of domains to understand the impact of each key concept. You will deconstruct a domain hierarchy to examine best practice architectures before constructing a domain hierarchy in a lab.
Module 3 explores settings that determine data access. This module focuses on how the domain assigned to a record sets its "context" and dictates the process logic run against it, the presentation of it, and the data accessible from it.
Module 4 begins the initial instance configuration to support domain separation. Module 4 reviews the Domain Configuration dashboard, common fields used in domain separation, and key business rules that assign domain values to records. The labs in Module 4 provide hands-on experience creating a domain separated table and building out several domains as part of a case study.
Module 5 expands on the key concepts to review a set of controls that enable more precise controls for data access. You will practice reading and interpreting domain hierarchies to better evaluate the effectiveness of various architectures. Robust Labs for this Module increase your understanding of how to position a Support Technician within the hierarchy and refine the architectural design for Cloud Dimensions.
Module 6 focuses on core data and security typically established during the beginning of a deployment or on-boarding for a new customer. The module covers users and groups as well as best practices around security and role assignment. Module 6 discusses Delegated Administration and which roles are suitable to be delegated to customers and users in child domains. Common integrations (LDAP and SSO) are explained within the framework of a Domain Separated instance.
Module 7 focuses on user interface concepts such as form layouts, list layouts, navigation menus, and home pages in a Domain Separated instance. Students explore the capabilities supported and best practices for making such customizations typically done during initial configuration of an application and when on-boarding new customers.
Module 8 dives into domain separation support for key applications on the platform such as Service Catalog and Knowledge. It also provides guidance for exploring domain support for other applications available both in the core platform as well as from third-parties.
Module 9 extends the discussion into workflow automation used to onboard new customers into a Domain Separated instance. The ideas of template workflows, workflow overrides, subflows, and the Workflow Operations Dashboard are discussed and created in the labs.
Module 10 focuses on integrations in a domain separated environment as well as some typical integrations common to managed service providers. Module 10 compares Domain Separation as an instance architecture to other instance architectures such as Express and separate instances. Students will explore options for managing shared data when integrating with customer systems.
Module 11 focuses on establishing development and management practices to ensure proper management of the environment. This module covers update set strategies, upgrade risks, and common governance considerations. Module 11 offers a discussion of common questions and allows students to generate reports and dashboards to manage the environment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-06-2018 10:53 PM
Hi Chuck,
I have one issue facing in MSP instance. I have created one domain in MSP instance.When as a admin I create a incident on the incident form the domain field is showing my domain name and once I submit it the domain name is showing as Global in list view, The same is happening in Problem record also.
But when I impersonate as an ITIL user the domain name is showing perfect in the list view.
Can you please share me some inputs on this how to resolve this issue for admin user.
Regards,
Gourav

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-07-2018 05:36 AM
When you create any ticket, like Incident, the domain will reflect the same as the User creating the ticket. You can override that by using the domain picker and choosing the domain you want the ticket created in.