If you have the need to manage each playground as a service, the prescribed method would be to define a different Offering for each of the individual locations, and then add the Location to the Subscribed Locations list, and also to the Location attribute for ease of identification. There is no CI Relationship needed, per se, as the Parent field of each offering will reference the TennisScheduling business service (if desired you can configure the Dependency Map to show this reference visually). If you are scheduling a Change for a specific location, say for construction or repair or renovation purposes, and you want to notify users of a Planned Outage on that playground (Offering), then this is easily accomplished by using the Offering as the CI on the Change Record. Users who are in that Location will have ability to make scheduling requests to book a future reservation using the Service Catalog, and they will have visibility to the related Catalog Items based on a match of the User's Location to the Offering's Subscribed Location. And if you have a Scheduling Application or other Application Services that you depend on for that Offering, you can relate the Offering to the appropriate deployed application instance.
And all of this is aligned to the Common Service Data Model.
Game and match.
The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.
