[Music] hi everyone welcome to glidefast on air i'm lauren jankowski the marketing manager here at glidefast and i'll be moderating today's webinar understanding domain separation in servicenow before we get started i'd like to give you some background information on glidefast glidefast consulting is a consulting firm that is dedicated exclusively to servicenow as an elite servicenow partner our expert team of developers and architects have worked on both sides of the table the customer side and the consulting side our company was founded by servicenow architects and we're proud to have a team of over 100 experienced consultants an average csat score of a 4.8 out of 5 and many more accolades as you can see here as a perk of attending today's webinar we'll be giving away a 50 visa gift card we'll announce the winner at the end of today's session so be sure to stay on for the entire webinar i'll be monitoring the q a throughout today's session so please send in any questions as they arise and we'll do our best to answer them now i'd like to hand things over to chris sanford a senior technical consultant here at glidefast yeah thank you lauren i'm chris sanford and i'm a senior technical consultant at glidefast and i've been working on servicenow platform for about six years now so today's topic is going to be on domain separation this is a feature that has been around since the early days of the platform but its capabilities are often misunderstood and newer customers are often reluctant to use it i've worked directly with customers that implemented domain separation and have also worked with customers that could benefit from some of its capabilities but were afraid they didn't have the ideal use case for it i think many customers are afraid to use domain separation because they are warned by servicenow that it cannot be removed from an instance once it is installed and they may have also heard stories from customers who implemented it the wrong way which led to technical depth that was difficult to clean up and also possibly user experience issues that could lead to poor user satisfaction with the product i will be covering today what domain separation is and how customers can benefit from its use what other alternatives they may want to consider and the different use cases for them and then go into a more technical deep dive on the components included in domain separation as well as tips and best practices for servicenow administrators and developers so uh moving on domain separation provides logical data and process separation in a single servicenow instance based on assigning a logical construct called a domain to records in the database in a well-implemented domain separation solution domain separation is usually completely invisible to the end users outside of administrators developers and perhaps a few process owners domains can be automatically assigned to data records based on business attributes most often the company field once domain separation has been configured in your instance every time a user performs an action that requires a database lookup the query is appended with a filter based on what records the user's domain has access to the domain separation structure is hierarchical which allows for parent-child relationships where users in a higher domain automatically inherit visibility to lower domains i think it is important to emphasize the process separation component of domain separation because i think that there are a lot of customers outside of the primary use case of a managed service provider that have this need oftentimes large organizations will have multiple lines of business multiple service desks or even multiple process ownership groups working within the same application of the platform but with slightly different configuration needs for example two different lines of business may want to use their own notification templates need different drop down options for choice and reference fields or have different criteria for when certain fields should be mandatory visible or editable on the same table within the same application of servicenow you can meet these needs without domain separation but it can often be greatly simplified through the out of the box concepts of domain overrides for configuration files in the instance it is also important to note however that this does not mean you can delegate administration to users in a lower domain that are not authorized to view all of the instances data despite servicenow's previous name for process separation which was delegated administration a user with an admin role automatically has the ability to set their domain to global through the domain picker and will have access to all data in the instance administration of the instance needs to be at the top level from the organization departments or line of business that owns the instance before making a decision to implement domain separation it is important to consider the alternatives several other applications and platform components exist that solve some of the same problems as domain separation for example one that gets talked about a lot especially for managed service providers is customer service management or csm it is best practice to use customer service management if you are using your instance to interface with external customers csm introduces several platform components to make the platform easier to use for external customers and ensure data security with explicitly defined snc internal and snc external roles that come with csm you can ensure that external customers will not be able to access tables catalog items knowledge articles or portal components unless they are explicitly granted access to do so by default contacts with the customer role can only access data open by them csm also includes the concept of a customer admin role which extends to contacts access to all cases for their company and allows them to report on this data within the csm application with all of these capabilities you may be asking yourself if domain separation would still be necessary if you had csm but the two are not mutually exclusive in fact servicenow has an entire documentation article on how domain separation works within the csm application while csm can solve some of the same use cases as domain separation it is not designed for allowing external users to assume the role of a fulfiller within the instance or any role other than a customer or consumer also as mentioned earlier the customer admin role can grant access to all company data within the csm application only so if your customers need to use other applications within the platform such as it service management or it business management there's a good chance you're going to need domain separation so if you're considering whether or not you need domain separation on top of csm it really comes down to what your external customers need to be able to do when they log into the platform if they only need basic self-service reporting functionality on their company's account data csm may be sufficient domain separation is not the only way to restrict access to data in a servicenow instance if you have any development experience in the platform you're likely familiar with both query business rules and access control lists or acl similar to how domain separation works by filtering database queries before they are applied query business rules give you the control to do this using the glide record api and server side javascript code when you have use cases that only require restricting access to a small set of database tables developing custom query business rules may be the perfect solution oftentimes however a customer may think they only want to restrict access to a small set of tables but the database schema is more complex than they realize and there are other related tables that also need to be separated for example a customer who uses itsm may think the only tables they need to separate are the core task types like incident problem change and request but each of these modules also has a complex network of related records including child tasks slas approvals and possibly custom tables on top of that with domain separation a lot of this is already taken into account out of the box and configuration efforts could be greatly reduced with domain separation if you have a small set of users performing a niche role in your instance that need their access restricted such as a third party vendor with a small distinguishable set of tables that they'll need to access it's probably not worth implementing domain separation for this use case alone and instead you should consider the query business rules option it's also worth mentioning separate instances as an alternative to domain separation maintaining separate instances in my opinion is going to make it much more difficult however to reap the benefits of the servicenow platform particularly when it comes to high-level roll-up reporting and providing a single system of record for the enterprise that being said if you're a really large organization that has entirely or almost entirely distinct processes and it would be extremely difficult to reconcile the differences this may be a better option at least in the short term although domain separation provides for segregation of processes there are certain system properties and components that are global and need to be agreed on for the entire instance this is what the out of the box domain map looks like in a servicenow instance when you first install domain separation it's pretty straightforward designed for the use case of a managed service provider with a few demo companies existing as domain tenants within the instance there are a few important things to note about it however and possibly a few changes to the structure that you may want to make even if you are a managed service provider you will notice that there is a default domain placed under top it's important that you keep a default domain in the hierarchy as this is the place any record that can't otherwise get a domain assigned to it will go without a default domain important data such as tasks and user records could end up in the global domain which essentially means the rules of domain separation do not apply to the record at all and could be a huge security leak for your business for example a user from an ldap integration where the company field was not populated could end up in the global domain or a change request created by an admin account in the global domain could be put in the global domain by mistake you should continuously monitor any user task or configuration item records placed in the default domain and eliminate whatever is causing them to be placed there by being underneath top in the hierarchy this means that only users in the top default or global domain are going to have access to the data in the default domain and in general any data in a given domain will be visible to users in that domain users in its parent domains in the hierarchy defined by this domain map and users in the global domain the global domain is not included in the domain map but any record in the global domain is essentially excluded from the rules of domain separation you should never have any tasks ci or user data in the global domain with the exception of admin user accounts and possibly a few service accounts you'll also notice in the baseline domain map that the msp domain contains top for a complete data access which is what is called a contains domain and it's going to be important to understand the concept of contains domains and visibility domains and the differences between them when you're implementing domain separation so to cover the basics a contains domain gives users in the containing domain access to the data in the domain contained through the use of what's called the domain picker the domain picker is a drop down that any user can find under their system settings so that allows them to switch the domain of their user session context similar to the update set picker or application scope picker which you're probably familiar with if you're a developer it can be pinned to the nav header at the top of the page for your session in this example users that are in the msp domain will be able to switch their domain to top through the domain picker and once they have done so they will have access to view the same data in lists reference fields or choice fields as a user that was in the top domain for the remainder of their user session visibility domains work similar to contains domains with a few noticeable differences unlike contains domains which are applied from one domain to another visibility domains are applied at either the user or group level also unlike contains domains visibility domains do not require a user to switch their domain picker to see access to the data in the visibility domain they can always see this data regardless of their session contacts domain many msp use cases could benefit from a simpler structure and better performance by simply making the msp the top domain and placing all of the msp users there the main consideration when making this decision would be how often does the msp domain need its own processes that should not carry over to the lower domains by default as this is exactly what would happen with any processes in the top domain in general data flows up in the domain hierarchy and processes flow down so this means if you have data that is in the msp domain for example with this domain map then any user in the top domain because it's a parent domain are also going to have access to that data but users in a lower domain like msp technicians in this example are not going to have access to that data with processes it would be the other way around so a process defined at the msp level is going to apply to users in the msp domain as well as users in the msp technicians domain but would not apply to any of the sibling domains here or any of the users that are in the top domain if you do opt to keep the msp contains top structure you will likely also want to add a visibility domain for any msp users as requiring the use of the domain picker for users that are not educated on domain separation can be difficult and is a poor user experience one of the most important considerations when implementing domain separation is how will domains be automatically assigned to data you're probably not going to want to add the domain field to every form layout as a mandatory field because many of your end users will likely have no idea what a domain is out of the box incident data and most task records have their domain assigned based on the company field this happens through the domain set domain task business rule and similar rules exist on the user table and the base cmdb table company has also made a mandatory field on the incident form and several other forms by default now depending on the model of your business you may not want to tie domains to company it may make sense to substitute company with a different field and if you do this you'll want to substitute these business rules in mandatory fields with a similar structure on a different table such as departments or your own custom table these business rules give you coverage on automatic domain assignment for user task and ci data which is a lot of data in your platform but another important piece of automatic domain assignment is cascading domains through related lists and related records such as approvals workflows or child tasks this is handled out of the box on task data with the domain cascade domain task business rule this business rule i think is one of the biggest benefits of domain separation as automatically cascading domains to related records is something that i see developers often overlook when implementing a custom query business rule solution for data separation or they don't cover all of the use cases that you will get out of the box with domain separation another great feature of domain separation is that cascading for new related records happens automatically using a url parameter when opening a new record from a related list in the ui however business rules will be necessary if the domain of the parent record is subject to change after creation the use record domain for data property that i've singled out at the bottom of the list on the slide here is set to true by default when setting up domain separation what this does is determines what data you will be able to see in related lists reference fields and choice fields when viewing a form if the property is true you will see data the same as users in the domain of the record you're viewing plus visibility domains regardless of what is set in your domain picker if set to false the domain picker takes precedent typically i would recommend leaving the property alone if you keep the msp contains top structure that i showed earlier but if you decide to put msp users in top setting to false will give the top domain users more flexibility in populating reference fields which many times would be desirable for example populating the caller field for an incident for a different company with someone in the msp company may be a desirable feature covering a few basics on best practices when implementing domain separation as i mentioned earlier centralized administration is important for domain separation it is possible to put admin accounts in other domains besides top and global but it is really pointless as they can still change their domain to global in the domain picker and see everything by putting an admin account in a different domain you are likely just going to make them have to change their domain picker more often than they otherwise would and are not actually restricting their access to data at all also it's worth mentioning unlike the update set picker and application scope picker the domain picker does not remember your setting once you log out so every time a user logs in their setting in the domain picker is going to default to whatever domain is set on their user record that being said is likely still going to be necessary for users in delegated domains to update some application file type records such as reports that may or may not have what's called a domain override applied to them an example of this might be the report admin role it's going to be important that any users that are given this type of access have an understanding of how domain separation works at both the data level and the process level as domain separation and data separation in general can have implications that people without knowledge of domain separation will probably not understand i briefly touched on visibility and contains domains earlier but it's also good to know that it's best practice to avoid them as they will affect the complexity of every database query that runs on an instance and can quickly cause performance issues if you have too many of them this is another reason to favor the structure of putting msp users directly on top rather than using the contains domain that's included out of the box if you're a servicenow developer creating your own scoped application or modifying an out of the box application here are a few tips that will make your development efforts work in a domain separated instance when you create a new table or need an existing table to be domain separated and it isn't out of the box you can easily do this for nearly any table by simply adding a sys domain column it's going to be important however to think about how this field can be automatically assigned similar to how the out of the box business rules do this based on the company field and cascading to the related records finally you also have the option as a developer to add a sys overrides field to almost any process extended table a process extended table is defined as a table that extends the base application file or cis metadata table what i explained earlier on the domain map where processes defined at the top level will automatically apply to lower domains actually only holds true for tables that have the cis overrides field defined on them but there may be additional tables where you want this behavior a good example of this is reports without assist overrides fields a report created in the top domain is only going to be visible for users in the top or global domains but if you're looking to enable rollup reports that can be extended and shared to users in lower domains without creating a separate report in each of those domains you could do this by adding assist overrides fields to the sys report table when you have this field users in lower domains will be able to see your report in the top domain but if they make any edits to it it will create a new report that overrides the top level one automatically this is what's called a domain override and is a key component of process separation functionality so that's all the contents i wanted to cover thank you to everyone who sat through this entire presentation i know it was a lot of content and hopefully you learned something useful from it i'll stay on to answer any questions that you may have awesome yeah it looks like we do have a couple questions chris so i'll read you some of those um if i installed domain separation and i later wanted to disable it is it easy to do so yes i i think so so it can't be completely removed from an instance and this is something that servicenow is going to warn you about if you're looking at installing domain separation but there is a system property that you can set to false that'll disable domain separation in your instance and i think a lot of customers are worried about the fact that it can't be completely removed from an instance but i think this is actually the case with a lot of other plug-ins as well and not just domain separation and so if you did need to disable it later you shouldn't be left with much technical debt and if there were any issues after disabling the property you should be able to fix them by migrating all of your records into the global domain through fixed scripts which should exclude them from being subject to any domain separation constraints awesome um looks like we have another if i develop code that queries the database will it be subject to the rules of domain separation yes yes that's a good question and unlike uh access control lists which are ignored kind of through when you're using the glide record api the the glide record api that you use to query records in the database is going to be subject to domain separation based on whatever user context triggered the database query uh querying through the rest api would work in a similar way and there are there are actually ways around this though there's actually a glide record method called the query no domain method but it's best practice to avoid it whenever possible because usually if you're obligated to keep your data domain separated you would want it to apply to code as well but the the query no domain method i think is a benefit of domain separation over query business rules because unlike query business rules where i've seen it's a lot harder to bypass those in code the the query node main method that comes with domain separation does give you that option even though you should use it sparingly awesome um looks like we got another question does domain separation work with security incident response and vulnerability response that is a good question and i i don't know the answer to that i'll have to follow up on that you should be able to find it on the documentation every application that's supported by servicenow is going to have different levels of support for domain separation i would imagine that they would at least have level one support which means that they support the model of separating data logically by domain but they may not have um all of the logic that automatically populates stuff like you do with regular incidents but i'm not an expert on the security incident response or vulnerability management so i don't know the full answer for sure but could get back to you on that awesome and one more question for you does domain separation affect the processing of emails yes yeah so that's a good question and and it does and and i've see i have seen some uh like kind of unexpected results that can happen in inbound email when you're using domain separation so the the key thing to remember is like when an existing user sends an email into servicenow that's a reply to an existing record in the system the standard rules of domain separation are going to apply to that user so if the user doesn't have domain access to view the record in the system that they're trying to reply to then the reply isn't going to process correctly uh so usually that shouldn't happen but there there are some weird use cases where it could happen like say um somebody emails in a ticket and then they cc somebody that is in a different domain like maybe there's a third party vendor that happens to work for two different of your tenants i i have actually seen that happen before but when a new user sends in an email it's going to process your email as a guest user until an account is provisioned for them the guest user account should be kept in the global domain so that it doesn't get subject to those constraints and there's also an email property to enable automatic user provisioning for new users that email in i would recommend leaving that off and coming up with some other way to handle your automatic user provisioning if you're using domain separation because that property is just going to put every user in the default domain and there's no there's no easy option to change that and usually that's that's not going to be what you want but so long answer but yes domain separation does affect processing of emails awesome well that looks like all the questions that came in so i guess now we can announce the winner of our fifty dollar visa gift card and it looks like the the winner is richard janaki congrats richard um you'll be getting a 50 visa gift card through your email that you signed up for this webinar on thank you everyone we hope you really enjoyed this information if you have any more questions for chris just reach out to him at chris sanford at glidefast.com or you could find us at info glidefest.com thank you everyone and enjoy the rest of your day [Music] [Applause]