WSD Location Architectural Best Practices

[Raj_Esh]

Heyllo Everyone,

I often get questions about the location table for WSD. Here’s a some guide for new WSD implementers on designing a scalable and maintainable data model and relationship framework that can support dozens to hundreds of buildings. This Article is created by keeping leaning from my CTA Experience in my mind.

1. Define Your Objectives on WSD locations

• Core Use Cases: Identify your primary needs( like room bookings, workstation or parking place or etc.

• Scale Requirements: Estimate the number of sites and regions you’ll would need for now and in the future.

• Alignment: Ensure your data model supports business goals and delivers a smooth user experience.

2. Establish Your Data Model

• Use Standard CI Classes: Leverage ServiceNow’s OOTB CMDB classes (Building, Floor, Room) rather than creating custom tables.

• Standard Attributes: Include fields such as Name, Address, Coordinates, Capacity, and Zone.

3. Design Relationships

• Containment Hierarchy: Model a clear Building → Floor → Area structure with one-to-many relationships.

• Logical Zones: Group buildings by region (For example, EU --> Germany --> Frankfurt --> Building A or Building B)

4. Define Naming Conventions

• Consistent Keys: Prefix CI names with region or campus codes (for example, EU-DE--FFM-BLD1) Optional

• Readable Labels: Combine friendly names with unique IDs to support both end users and integrations.

• Version Tracking: Use a dedicated attribute (or description) to note major changes, like building expansions.

5. Plan for Scale (not recommended but if the company has huge CMDB location data)

• Partition by Region: For very large deployments, consider scoped CMDB partitions or multiple CMDB instances. Optional

6. Governance and Maintenance

• Roles & ACLs: Define clear permissions for creating, updating, and retiring CIs at each zone level.

• Data Ownership: Assign a data owner for each region or business unit and conduct regular audits.

• Monitoring: Use CMDB Health and WSD dashboards to spot orphaned or outdated records.

7. Onboard New Buildings

• Import Templates: Develop standardized Process templates that match your data model.

• Staging Area: Import new site data into a sandbox zone for validation before promoting to production.

• Automated Validation: Build flows to automatically check for naming conflicts or relationship errors.( ServiceNow has few OOTB validations)

8. Summary

A strong WSD implementation is built on a well-designed data model and clear relationship framework. By following these best practices standard CI usage, defined hierarchy, consistent naming, and solid governance one can create a foundation that scales gracefully with any organization.

Hope it helps to someone somehwhere who is looking for idea on WSD Location Architectural Best Practices

Products articles