Blog > October 19, 2026

OSH software for multisite companies: organising roles, data and site-level follow-up

Multi-site OSH: organise roles, data and monitoring by site.

Managing occupational risk prevention across several sites requires shared criteria alongside decisions made close to the work. Management needs an overall view, while each location needs to act on its own risks, people and preventive measures. Software should support both perspectives without assuming that consolidated reporting means identical operations everywhere.

Article 16 of Spain’s Occupational Risk Prevention Act places prevention within the company’s activities and management levels. The Explora entry on the prevention plan helps translate this principle into responsibilities, procedures and resources for a multisite organisation.

Design the structure before importing people

Distinguish legal entity, site, area and job. Assign stable identifiers and decide who can create or change each level. If two sites use the same job title, check whether duties and working conditions are genuinely equivalent before sharing an assessment or applying a common rule.

Record the dates of important changes. A transfer should not rewrite the historical location of training or an action. When a site opens, merges or closes, determine which records remain active and how historical information will be consulted. These rules prevent ambiguity when later reports are prepared.

Decide what is shared and what requires local judgement

The organisation can share status definitions, incident categories, priority criteria and tracking formats. Local owners need to adapt activities to real work and explain justified differences. Copying every record from one site to another may carry assumptions that do not apply to the second location.

The Explora entry on risk assessment reinforces the relevance of actual working conditions. A common catalogue can provide support, but technical review must establish the scope of each assessment and the measures appropriate to the particular site, task and people involved.

Test permissions through specific tasks

A user role should reflect responsibilities, not merely a job title. Someone may manage two sites and consult only selected information at a third. A temporary replacement needs access during the assignment and a review when it ends. Document these situations before configuring the permissions model.

Use different test accounts during the demonstration:

  • Local owner: records and follows up actions at their site.
  • Corporate team: compares results and reviews matters requiring central support.
  • Specialist: works on assigned cases within the agreed remit.
  • Temporary replacement: performs authorised duties during the defined period.

Also test what each role cannot view or change. A site filter on screen does not, by itself, establish separated access rights. Include searches, documents, exports and direct links in the agreed test scope. Record unexpected access as an issue requiring resolution before deployment.

Build indicators that support comparison

Before combining results, define formulas, reporting periods and data sources. Distinguish counts from rates and proportions. A simple average of percentages from sites of different sizes can produce a misleading picture. Use the calculation appropriate to the underlying data being consolidated and explain it consistently.

The Explora entry on OSH indicators helps define these criteria. Show the scope and update date beside each result. A site with incomplete information should be marked accordingly rather than appearing to have no incidents or outstanding activities simply because data is missing.

Evaluate a realistic working example

Imagine three warehouses implementing a corporate action on internal traffic. Each location must assess its application, assign owners and supply its own evidence. The central team wants progress visibility without collectively closing actions that still need local verification and site-specific decisions.

This is an illustrative test case. It should identify the shared initiative, its implementation at each location and reasons for any deviation. Add a change of owner to confirm that follow-up continues and the history still shows who made earlier decisions and when.

Organise deployment and review

Start with representative sites and document configuration decisions that should remain consistent during expansion. The software implementation guide explains this process. If contractors also work at your sites, examine the relationship between CAE platforms and internal prevention before defining overlapping records or exchanges.

When considering Sabentis OSH software, ask to see the organisational structure, permissions and a complete multisite tracking workflow. This connects the corporate view with the preventive work that each site needs to perform.

A practical checklist for adding a new site

Before copying an existing site’s configuration, use these checks to identify differences that a corporate catalogue might conceal. Adding the site should preserve local context and a traceable history of decisions.

  • Compare identically named jobs and record differences in tasks, equipment, environment or shifts that require technical review.
  • Identify who will accept the site’s initial data and which checks they will perform before it is used.
  • Test a person’s transfer between sites without changing the historical location associated with their previous activities.
  • Check that a temporary owner loses exceptional access when cover ends, while their decision history remains available.
  • Test a corporate report containing a site with no data for the period and confirm that the absence is explicitly shown.

Frequently asked questions about multisite OSH software

Can one job assessment be reused at every site?

A catalogue can provide a reference, but assessment must consider actual working conditions and the people exposed. Jobs with the same title may use different equipment or methods. Competent review should establish which information can be transferred and which parts require adaptation to the local context.

What should happen when a site closes?

Separate operational closure from record retention. Remove unnecessary access, preserve historical context and identify outstanding actions and their new owners. Avoid deleting the site as though it never existed, since that could break the interpretation of activities and decisions recorded before closure.

Does management need access to every personal case file?

Management needs information appropriate to its decisions, but that does not imply unrestricted access to every file. Define views and permissions by function. Health data has specific access restrictions; corporate oversight can use aggregated information without exposing clinical details to people who are not authorised.

How can we check the model works for a different site?

Select a location with conditions different from the pilot and test a complete workflow with its users. Include a local change and an exception to the common catalogue. The test should show what is shared, who authorises adaptation and how monitoring remains comparable.

Legislation and sources consulted

Sources consulted on 6 October 2026. Checklists and examples are practical implementation proposals.

Request a Demo

Discover all that Sabentis can do for your organization.

Try Sabentis

request a demo
stars 5
GetApp Software Advice Capterra