Updating a Project to a Multi-Site Campus Structure

Purpose

To outline the steps required to convert an existing Sitemetric project into a multi-site campus, establish parent/child site relationships, migrate sensors, and correctly align workforce access permissions.

Scope

This procedure applies to Sitemetric support, Field Techs, and Site Leaders involved in project configuration, sensor management, and access list setup for any GC converting to a campus model

Procedure

1. Launch New Campus Project (Parent Site)

• Launch new Campus project in the admin
• Update the existing (Child) project in the Admin Portal to under the new Parent
• Rune one time backlog sync so all existing workers on the child project gain access to the new Parent campus project
• Name bew parent project to Campus standard naming convention (Project Name ‘Campus’).
• Confirm project naming and activation parent/child linking.
  • Parent sites
    • Click on site settings and update the following 3 fields to include the name ‘campus’

• Result:
  • New campus project launched
  • All child project access lists will sync to the campus.
  • Manually backlogged existing workers on the child site so they have access to the parent/campus project
  • Campus will have equipment for the shared access point.

2. Create New Child Sites

• Submit new site launch requests for all new child sites
• Launch and configure project details for each site.
• Configure site settings to link the Child site(s) to the Parent site.Child sites
  • Edit site details and select the correct site for the ‘Parent Site:’ field
• Result: New active child sites linked to the campus.

3. Reassign Sensors to the Appropriate Child Projects

• Review existing equipment assigned to the parent site.
• Identify physical deployment locations.
• Reassign equipment to the correct child sites.
• Confirm proper data flow.
• Once equipment is assigned, create a task to turn on all standard reports for each child site
• Result: All equipment mapped correctly and reports turned on.

4. Transfer the Full Access List to Each Child Site

• Export the access list from the parent project.
• Ensure all active workers receive full site access initially.
• Result: All workers temporarily have access to all child sites, so data flow is not disrupted during the transition

5. Obtain Contractor Assignment Information from Customer/GC

• Determine whether the client wants:
  • Shared access lists (all child sites use the same list)
    • Apply the parent access list to all child sites and turn on site setting to automatically sync access.
  • Unique access lists per child site.
    • Apply the parent list as a baseline, then adjust or register workers according to contractors that should be assigned per child project
      • Request contractor-to-project mappings
    • Result: Confirmed how to handle worker site access.

6. Update Access Lists to Match the Confirmed Assignments

• Apply the contractor assignment matrix to update each child site or turn on the shared site access sync setting.
• Remove unassigned workers, add shared contractors appropriately.
• Validate accuracy of worker placement.
• Notify Customer of completion.
• Result: All access lists updated to final configuration.

Completion Checklist

• Parent site converted to campus
• All child sites created and linked, If child site existed previous to the campus, manually sync access list to the new parent project
• Access list cloned to all child sites
• Equipment reassigned
• Request to add standard reports to all new sites
• For unique access lists: Contractor assignment received
• Access lists updated to final configuration (Shared or Unique)
• Customer notified of completion