EHS Software Integrations: Connecting Safety Data Without Another Silo

Connect the platform to the places your safety data already lives, starting with read access to one source that answers a question you ask every week. Treat write access to other systems as an exception that needs a named owner and a written reason.

A safety platform that cannot see your mailboxes, document libraries or HR records depends on someone retyping that information. This guide covers where safety data usually sits, how to choose a direction for each connection, the questions to put to any vendor, and how to start with a single source.

Where safety data actually lives

OSHA's Recommended Practices for Safety and Health Programs start hazard identification by collecting information the employer already has. The internal sources OSHA lists include equipment manuals, Safety Data Sheets, inspection reports from insurers and agencies, injury and illness records, workers' compensation records and job hazard analyses (OSHA: Hazard Identification and Assessment). In most organisations those documents are spread across systems the safety team does not own:

• Email. Incident reports from supervisors, contractor correspondence and letters from regulators arrive here first, and many never leave.
• Shared folders. SharePoint, OneDrive or Google Drive hold policies, procedures, risk assessments and Safety Data Sheets, often in several versions.
• Chat. A near miss is often mentioned in a Teams or Slack channel and never written up as a report.
• HR systems. Roles, sites, start dates and training assignments sit in the HR system of record.
• ERP and maintenance systems. Assets, work orders and equipment history live with operations and maintenance.
• Spreadsheets. Incident logs and corrective-action trackers kept by one person, sometimes for years.
• Insurer and broker systems. Loss runs and claims history, held outside the organisation altogether.

The silo forms when the safety platform holds only what someone typed into it. The hazard register can be accurate on its own terms and still miss the forklift complaint that sits in a supervisor's inbox.

Read, write or neither: choose a direction for each source

"Integration" sounds like one decision. In practice it is a separate decision for every source, and each one has a direction.

Read. The EHS platform looks information up in the source, and the source stays the system of record. This covers most of what a safety team needs: the current version of a procedure, the email thread about an incident, the list of people in a role at a site.

Write. The EHS platform creates or changes something in another system, such as a maintenance work order or an HR training assignment. That can save real effort, and every write needs an owner in the receiving system, a rule for duplicates and conflicts, and a person who checks the result.

Neither. Some data should stay out of scope. OSHA's own list includes exposure monitoring results and medical records only when appropriately redacted to protect worker privacy. If a workflow does not need a field, do not connect it.

Security teams have a name for this habit. The principle of least privilege, as NIST's glossary defines it, restricts the access of users and of processes acting on their behalf to what their tasks require (NIST CSRC glossary). An AI assistant searching your document library is a process acting on someone's behalf, so the same rule applies. Read access is also easier to approve, because a mistake cannot alter the source record. Our recommendation is to start every source on read and add write access only when a specific workflow cannot run without it.

An integration map for a typical safety team

Use this table as a starting point for your own inventory. The directions are recommended defaults. Adjust them to your workflows and to what each system owner will accept.

If you are replacing a platform at the same time, rebuild these connections before go-live. The EHS software migration checklist covers the order of work.

Questions to ask any vendor before you connect anything

These questions suit the meeting where IT and security join the evaluation. Ask for the answers in writing, per connector.

1. Whose identity does the connection use? A connection made with an individual's sign-in can usually see only what that person can already see. A shared service account may see far more. Ask which permission scopes each connector requests and whether you can narrow them.
2. Can it change anything, and where are the exceptions? A general statement about the platform describes the default. The documentation for each app shows the exceptions. Ask what the tool may do in each connected system and what it is blocked from doing.
3. What happens to the data? Ask whether content is fetched on request or copied and stored, where any copy is kept and for how long, whether it is used to train models, and what happens to the copy when the original is deleted.
4. What is logged? Ask whether you can see which connector was used, by whom and for what, and whether the source system's own audit log can tell the tool apart from the person.
5. How do we switch it off? Ask how to disconnect one source without affecting the others, what happens when an access token expires, and what remains on the vendor side afterwards.
6. Who has to be involved in setup? Some connections need an administrator to install an app or approve access for the whole organisation. Others need firewall changes. Find out before you plan a pilot date.
7. Will it conflict with tools we already run? An attendee at Soter's June 2026 product webinar on connecting safety systems asked whether an AI assistant already running across their Microsoft apps would interfere with the new connectors (webinar recording, 10:15). Ask every vendor the same question about the assistants and automations you already have.

For the wider evaluation, including workflow depth and data ownership, see how to choose an EHS platform in the AI era.

How to start with one source

Connecting everything on the first day makes it hard to tell which source produced a useful answer and which produced noise. A single source gives you a clean test.

1. Pick a weekly question. Choose one your team answers by hand today, for example "What did contractors raise about the permit-to-work process this month?"
2. Find the source that holds most of the answer. For that example it is probably a mailbox or a chat channel. Resist adding a second source until the first one works.
3. Connect it with read access under a named user with ordinary permissions. Keep administrator accounts out of the test.
4. Ask the tool what it can see. Before testing answers, ask it to list or describe what it can access. Missing folders or channels usually point to a permission gap, and that is cheaper to find now than after rollout.
5. Test with five questions you already know the answers to. Record each miss: an old version of a document, a private channel outside scope, a long thread read only in part.
6. Write down the connection. Record its owner, scope, direction and how to disconnect it. Then decide on the next source.

Data quality matters as much as access. If the first source turns out to be full of duplicates or outdated files, fix that before connecting more. The article on fixing data quality and access before agentic AI covers both problems.

Where SoterAI fits

In SoterAI, connections are added from the Connectors panel, the puzzle-piece icon in the chat input bar. Self-serve connectors listed in the Help Centre include Gmail, Google Calendar, Google Drive, Outlook, Microsoft Teams, SharePoint, OneDrive, Slack, Jira, Confluence, Box, Dropbox, Salesforce, Monday.com, Databricks, Snowflake and Origami Risk. Applied Epic, Vertafore ImageRight, Vertafore Sagitta and Duck Creek are listed as assisted setup: they need credentials only your organisation can issue, and the Help Centre says each one requires allowing SoterAI's outbound traffic through your firewall (Connecting External Apps to SoterAI).

The Help Centre describes these connections as read-only: SoterAI can read and search connected files and data. Each app guide sets out the exact scope. The SharePoint guide, for example, covers document libraries and lists, and excludes sites your account cannot view. The Slack and Teams guides exclude channels and conversations you are not a member of. The Gmail guide documents creating drafts and states that SoterAI cannot send, reply to or forward email. For IT and security reviewers, a connection that reads within the user's existing permissions is a simpler approval than one that writes. A connection appears in the Connected tab, where it can be disconnected.

For systems without a listed connector, the Help Centre describes a custom API connector configured with a base URL, API documentation and either API keys or OAuth2 client credentials. It advises credentials scoped to the minimum access you need. Exported incident logs and corrective-action histories in CSV or Excel can be uploaded to Data Sources. The Help Centre says SoterAI ingests that structured data to populate the risk register and trend analyses (Data Sources Overview).

Chat also works in the other direction. People can use SoterAI from inside Microsoft Teams or Slack to ask questions, run workflows and submit records into SoterAI. In Teams, an IT administrator installs the app package in the tenant (Using SoterAI in Microsoft Teams). The SoterAI Teams integration article shows the Teams experience in more detail. The full list of guides is on the Integrations page, and security documentation is in the Trust Centre.

See which systems SoterAI connects to and read each guide. Open Integrations.