Data relationships

Data model overview

This page is your map of SafetyCulture data across Exporter, the Power BI connector, and the Data Feeds APIs. It shows how datasets relate, which keys to join on, and where to start organized into four domains: People, Work, Tasks, and Structure.

How to use this page

Start with a question. Example: “Who is a member of each site?”
Open the relevant domain slice. For the example: People.
Use the diagram + key join callouts to build your relationships. Example joins: site_members.member_id = users.user_id, site_members.site_id = sites.site_id.

📘
Export and access methods
Use SafetyCulture Exporter for ad-hoc or scheduled bulk files, Power BI connector for direct dashboards, and Data Feeds APIs for programmatic, incremental pipelines. Review the decision guide for trade-offs.
All three access paths expose the same logical model and only the transport differs.

Domains

Domain slice	Go here for	Datasets	Primary bridges to other slices (join keys)
People([/data/people])	Info about users, groups, memberships, or learning status.	`users`, `groups`, `group_users`, `site_members`, `course_progress`	To Structure: site_members.site_id → sites.site_id To Work/Tasks: user_id on authors/owners/assignees Alias note: site_members.member_id = users.user_id
Work([/data/work])	Define, plan, and analyze work (forms, schedules, inspections).	`templates, inspections`, `inspection_items, schedules`, `schedule_assignees`, `schedule_occurrences`, `activity_log_events`	To Structure: site_id on work records To People: user fields (authors/owners/assignees via `user_id`) Within Work: `inspection_items.audit_id → inspections.audit_id`, `inspections.template_id → templates.template_id`
Tasks([/data/tasks])	Track actions/issues, ownership, and timelines.	`actions, action_assignees`, `action_timeline_items`, `issues`, `issue_timeline_items`, `issue_relations`	To People: assignees `user_id` / `group_id` To Work: links to work items (for example, `inspection_id`) To Structure: `site_id` on actions/issues (where present)
Structure([/data/structure])	Work by location or asset.	sites (hierarchy), assets	From People: `site_members.site_id → sites.site_id` From Work/Tasks: `site_id` on inspections, actions, and (sometimes) issues

Data diagrams per domain

📘
Legend

Purple box = dataset (table/feed).

Box with a dotted border = Link tables (many↔many bridges)

Cardinality (crow’s-foot)

↣o (circle + crow’s-foot) = 0..* on that side (optional, many).

| (single bar) = exactly one (1).

|| (double bar) = one and only one (mandatory 1).

Join notation: child_fk → parent_pk

People ↔ Structure model (Users, Groups, Site membership)

Use these datasets to relate users/groups to sites. The link tables are group_users and site_members (alias: site_members.member_id = users.user_id).

Entities

Dataset	Primary key	Purpose
`users`	`user_id`	People in your organization.
`groups`	`group_id`	Cohorts for permissions/assignment.
`group_users`	`(group_id, user_id)`	Link table: users ↔ groups
`sites`	`site_id`	Locations (often hierarchical)
`site_members`	`(site_id, member_id)`	Link table: users ↔ sites (member_id = users.user_id)
`course_progress`	`internal id or course_id + user_id`	Per-user learning/enrollment/progress

Join cheat sheet

From (child)	To (parent)	ON (child_fk → parent_pk)	Notes
`group_users`	`users`	`user_id → user_id`	—
`group_users`	`groups`	`group_id → group_id`	—
`site_members`	`users`	`member_id → user_id`	Alias
`site_members`	`sites`	`site_id → site_id`	—
`course_progress`	`users`	`user_id → user_id`	Roll up by site via `users` → `site_members → sites`

🪄
Cross-slice pointers for orientation

To Work: joins typically use user_id (authors/owners/assignees) and site_id (where inspections occur).

To Tasks : assignee tables reference user_id/group_id; actions/issues may also carry site_id.

Work data model (Templates, Inspections, Item responses, and Template access)

This diagram shows how work is defined and executed. Templates define the work; inspections are the runs of that work; item-level responses live in inspection items; and template permissions control who can use/manage each template. Cross-domain bridges are shown to Sites (where work happens) and Users/Groups (who can access or authored the work).

Entities

Dataset	Primary key	Purpose
`templates`	`template_id`	Definition of work (forms).
`inspections`	`inspection_id` or `audit_id`	Executed runs of a template.
`inspection_items`	(impl PK; joins via inspection key)	Item/question-level responses.
`template_permissions`	(impl PK; joins via `template_id`, `user_id`/`group_id`)	Access/usage rights for templates.
`schedules`	`schedule_id`	Planned work.
`schedules_assignees`	Internal/opaque ID or composite (varies)	Per-user learning/enrollment/progress
`schedules_occurrences`	Internal row ID (not required for joins)	Generated instances of planned work.
`sites`	`site_id`	Location context (Structure slice).
`users`	`user_id`	People context (People slice).
`groups`	`group_id`	Cohorts (People slice).

Join cheat sheet

From (child)	To (parent)	ON (child_fk → parent_pk)	Notes
`inspection_items`	`inspections`	`inspection_id → inspection_id`	Use canonical key (`inspection_id` or `audit_id`).
`inspections`	`templates`	`template_id → template_id`	—
`inspections`	`sites`	`site_id → site_id`	Cross-slice bridge to Structure.
`inspections`	`users`	`author_id → user_id` (or `owner_id → user_id`)	Choose field name used in feeds.
`template_permissions`	`templates`	`template_id → template_id`	Link table
`template_permissions`	`users`	`user_id → user_id`	Link table
`template_permissions`	`groups`	`group_id → group_id`	Link table
`schedule_assignees`	`schedules`	`schedule_id → schedule_id`	Link table
`schedule_assignees`	`users`	`user_id → user_id`	Link table
`schedule_assignees`	`groups`	`group_id → group_id`	Link table
`schedule_occurrences`	`schedules`	`schedule_id → schedule_id`	Link table

Tasks (Actions, Issues, assignments, and relations)

Use these datasets to model task ownership and traceability across your environment. Actions and Issues live at sites, are assigned to Users/Groups via link tables, and Issues can relate back to Inspections and Actions for end-to-end traceability.

Entities

Dataset	Primary key	Purpose
`actions`	`action_id`	Remediation/next-step tasks; can be site-scoped.
`action_assignees`	internal/composite	Assigns actions to users and/or groups.
`issues`		Reported issues/incidents; can be site-scoped.
`issues_assignees`	internal/composite	Assigns issues to users and/or groups.
`issue_timeline_items`	internal row id	Status/history events for an issue.
`issue_relations`	internal/composite	Traceability links: issue ↔ inspection/action.
`inspections`	`inspection_id` (or `audit_id`)	Referenced by `issue_relations`.
`sites`	`site_id`	Location context for actions and issues.
`users`	`user_id`	Actors/assignees.
`groups`	`group_id`	Cohorts for assignment.

Join cheat sheet

From (child)	To (parent)	ON (child_fk → parent_pk)	Notes
`action_assignees`	`actions`	`action_id → action_id`	Link table
`action_assignees`	`users`	`user_id → user_id`	Link table
`action_assignees`	`groups`	`group_id → group_id`	Link table
`actions`	`sites`	`site_id → site_id`	Site context
`issue_assignees`	`issues`	`issue_id → id`	Link table
`issue_assignees`	`users`	`user_id → user_id`	Link table
`issue_assignees`	`groups`	`group_id → group_id`	Link table
`issue_timeline_items`	`issues`	`issue_id → id`	History of an issue
`issue_relations`	`issues`	`issue_id → id`	Traceability root
`issue_relations`	`inspections`	`inspection_id → inspection_id (or audit_id)`	Keep key label consistent with Work slice
`issue_relations`	`actions`	`action_id → action_id`	Links issues to actions
`issues`	`sites`	`site_id → site_id`	Site context

Structure data model (Sites and Assets)

Use the Structure slice to answer “where” things happen and to roll up all other data by location. Sites form a hierarchy (such as Region → Facility → Area). Assets are equipment/objects that usually live at a site. Other slices (Work and Tasks) reference Sites via site_id.

Entries

Dataset	Primary key	Purpose
`sites`	`site_id`	Location nodes in a hierarchy. Self-join on parent to model hierarchy.
`assets`	`asset_id`	Equipment/objects located at sites. Typically carries `site_id`.
(bridges from other slices; not entities of this slice)	—	inspections, actions, and sometimes issues each carry site_id to link back to sites.

Join cheat sheet

From (child)	To (parent)	ON (child_fk → parent_pk)	Notes
`sites (child)`	`sites (parent)`	`parent_site_id → site_id`	Models site hierarchy (root sites have NULL parent).
`assets`	`sites`	`site_id → site_id`	Places assets at a site.
`inspections` (Work)	`sites`	`site_id → site_id`	Some orgs allow inspections without a site; LEFT JOIN if nullable.
`actions` (Tasks)	`sites`	`site_id → site_id`	Site context for actions.

Updated about 3 hours ago