1. Dataset name

Usage - Resource Management

2. Description

Event-level dataset that records each user activity in Resource Management, with one row per qualifying server request. Each row shows who performed the activity, their role (Program/Project/Resource Manager, Line/Capacity Manager, or Employee), and, where the activity relates to a demand, that demand's business unit, job function, and location country. It is built from customer_views.www_server_log, filtered to Resource Management namespaces, events, and request paths. User display names come from customer_views.employee and demand attributes from customer_views.positions. It is designed to be the primary source for Resource Management adoption and engagement analyses.

3. Source tables

• customer_views.www_server_log — base event log; the anchor of the dataset
• customer_views.employee — resolves user display names, deduplicated to the most recent record per employee email
• customer_views.positions — provides demand attributes (business unit, job function, location country) for demand-linked activity

4. Grain

One row per qualifying Resource Management server request (event) in customer_views.www_server_log. Each row is a single user action, such as a page load, search, booking update, or nomination. One user produces many rows. customer_views.employee and customer_views.positions are LEFT JOINed onto the event, so an event is kept even when no employee record or position matches it.

5. Dashboards supported

• Resource Management

6. Metrics supported

7. Known exclusions and filters applied

• Events with a null user_email, or from the logged-out placeholder user (loggedout@none.com), are excluded.
• Only successful requests are kept: events with response_code ≥ 400 are excluded.
• An event is included only if it matches one of the following Resource Management activity rules:
  • Namespace resourcing with one of the defined resourcing events (homepage, org units, demand hierarchy, staffing overview, projects, demands, demand insights, resource search, demand calibration, publish settings, demand applications)
  • Namespace position_sync, event demand_calibration_sync
  • Namespace employee_availability with one of the defined holiday, booking, availability, position, and profile events
  • Request paths /demand/pipeline_v2, /demand/calibration, /demands/calibration/log, or /resourcing/feedback/dashboard, regardless of namespace or event
  • Namespace career_hub with events demand_search, demand_view, get_bulk_reports_bookings, or get_bulk_reports_availabilities
  • Namespace career_hub, event profile_my_pages, limited to the request paths for "My demand applications" and "My saved demands"
  • Namespace career_hub/my_bookings with the defined My Bookings events
  • Namespace career_hub/manager_resourcing with the defined manager resourcing events (demand details, recommended demands, nominate/withdraw nomination)
• Namespaces employee_availabilit and career_hub/manager_r are truncated forms of employee_availability and career_hub/manager_resourcing as recorded in the log. They are matched the same way as the full names.
• user_type is assigned per activity, not per user, and is the canonical field for role-based breakdowns. A user who performs both manager and employee actions appears under more than one user type, so distinct-user counts across user types can sum to more than the total number of active users.
• user_email is lowercased before display names are resolved. When no matching employee record is found, user_name falls back to the raw email.
• demand_business_unit, demand_job_function, and demand_location_country are populated only for events that carry a position_id matching a position. Breakdowns by these fields therefore cover only demand-linked activity.
• The dataset logic applies no date filter; it covers all-time history.

8. Schema