Donesafe Module Selection: Where Teams Go Wrong
With almost 100 modules available across Health and Safety, Injury and Claims, Quality and Supplier, Risk and Compliance, and Environmental and Sustainability, the Donesafe catalogue is genuinely powerful. It is also where many mid-implementation teams hit a wall. They either select too many modules upfront and drown in configuration work, or they choose too few and discover a compliance gap when an auditor asks for something they cannot produce. Getting module selection right is not a catalogue exercise. It is a systems design decision.
The two failure modes: overbuilding and underbuilding
Teams often fall into one of two traps. The first is scope creep at selection: a safety manager sees modules for chemicals, contractors, learning, risk, audits, corrective actions and incident management, thinks they need all of them on day one, and commits to a configuration load that overwhelms both the implementation partner and internal stakeholders. The second is selection by gut feel: picking the modules that look familiar without mapping them to the actual compliance obligations the organisation carries. Both produce the same outcome, a system that does not get used the way it was intended, and ISO aligned frameworks (ISO 45001 for occupational health and safety, ISO 9001 for quality, ISO 14001 for environmental) require evidence of use, not just evidence of setup. A system your people do not trust is not an asset in an audit; it is a liability.
Start with your compliance obligations, not the module list
Before opening the catalogue, list what you are actually required to evidence. If your organisation operates under ISO 45001, you need incident and hazard management, corrective actions with an owner and a due date, audit and inspection records, and documented controls. If ISO 9001 applies, nonconformance management and supplier or quality records come into scope. ISO 14001 adds environmental registers and monitoring workflows. HACCP adds food safety controls. Map these obligations first, then find the modules that satisfy them. The modules exist to carry the evidence your standards require; the standards do not exist to justify the modules you liked the look of.
This discipline also prevents the common mistake of treating Donesafe as an upgrade of your old spreadsheet system, buying a module for every register that used to live in Excel rather than asking whether some of those registers need to exist at all.
Which module categories carry the most risk if you skip them?
Incident and hazard management is often underscoped. Organisations select an incident module but omit hazard reporting, which means near miss data never reaches the corrective action workflow. In a construction, mining or transport environment, that gap is both a compliance exposure and a genuine safety risk. ISO 45001 places weight on identifying hazards, not just responding to incidents, so check the standard and the legislation that applies to you.
Corrective action management is another common omission. Teams configure audits and inspections, find nonconformances, and then track the resulting actions in a spreadsheet sitting outside the platform. That disconnects the evidence trail. An auditor asking to follow a finding from inspection to closure needs to see the whole chain inside the one system, not a printout from somewhere else.
Contractor management is often underestimated by operations with several sites. Managing over 600 contractors and staff in one system, as Ontime Delivery Solutions describes doing with Donesafe, works best when the contractor module is properly integrated with induction, licence and document expiry workflows from the start.
Can you add modules later, or does the initial selection lock you in?
You can add standard modules after go live. However, adding a module that should have been present at launch is not cost free. If your incident module went live without a linked corrective action module, every incident record created in the interim has no automated pathway to a corrective action. Retrospectively linking those records, rebuilding the workflow logic, and retraining your team costs time and money that proper upfront selection would have avoided.
The practical answer is to prioritise the modules that sit in your core evidence trail for day one, and stage everything else in a structured roadmap. Modules that support nice to have reporting, for example trend dashboards or management review summaries, can wait. Modules that sit in the middle of a mandatory process cannot.
Custom modules versus standard modules: knowing the difference
A standard module covers a recognised compliance use case and is part of the platform's standard library. A custom module is built to cover a workflow that does not fit neatly into any standard option. Custom modules carry a higher design and maintenance overhead, so selecting one when a standard module would do the job is a waste of implementation budget and a future maintenance burden.
The decision point is whether your workflow is genuinely unique to your industry or organisation, or whether it just feels unique because your current process was built around the limitations of a spreadsheet. A good implementation partner will push back on custom module requests where a properly configured standard module, with the right workflow and form design, would produce the same outcome.
How do you handle modules that span multiple business units?
Multi-site and multi-business-unit organisations face an additional selection challenge: some modules need to behave differently depending on which site or business unit is using them. A single audit and inspection module can be configured with role specific dashboards so that a site supervisor in one location sees only their site's open actions, while a national safety manager sees the consolidated picture. The module selection decision here is not whether to have one module or many, it is whether the module's configuration supports the permission and visibility structure your organisation actually needs.
Getting this wrong can lead to a familiar problem: every user sees everything, so nobody trusts the data, and nobody uses the system. Role specific dashboards are a configuration choice, not a separate module, but you need to plan for them during selection, not after go live.
A practical selection process to apply before you commit
Work through these four steps before finalising your module list. First, list every compliance obligation you carry by standard, regulation and industry requirement, and check the legislation that applies to your jurisdiction. Second, map each obligation to the evidence type it requires: a record, a workflow, a register, a dashboard. Third, match that evidence type to the Donesafe module category that produces it. Fourth, sort the resulting list into must have at launch and can add later, using the test of whether the absence of the module breaks a mandatory evidence trail.
If a module does not appear in step three, it is a candidate for the roadmap, not the initial build. If a module appears in step three but has no corresponding obligation in step one, question whether it belongs at all. For organisations building a full WHSEQ system aligned to ISO 45001, ISO 9001 and ISO 14001, the core module set is likely to include incident and hazard management, corrective actions, audits and inspections, and contractor management. Everything else is scoped from there.
If you want to walk through this process with people who have been configuring Donesafe for over ten years across construction, mining, food manufacturing, transport and more, the KIS Group Donesafe service page is the right starting point. KIS Group also offers a free Donesafe demonstration, a live online session of 45 to 60 minutes.
Frequently asked questions
How many Donesafe modules does a typical organisation actually need?
There is no universal number. A sensible approach is to launch with the core modules that cover your mandatory evidence trail, then add more over time. Starting with too many can be more damaging than starting with too few, because it delays go live and produces a system nobody is trained to use properly.
What is the difference between a standard module and a custom module in Donesafe?
A standard module is part of Donesafe's standard library and covers a recognised compliance use case. A custom module is built from scratch to cover a workflow the standard library does not address. Custom modules generally take more design and maintenance work, so they are best chosen only where a standard module, even with full configuration, genuinely cannot meet the requirement.
Can you remove a module after go live if it turns out you do not need it?
Generally yes, but if the module has collected records that link to other parts of your system, removing it cleanly takes careful planning. This is another reason to be selective upfront rather than adding everything and pruning later. Data relationships between modules are easy to create and harder to undo once records exist.
Do module choices affect ISO audit readiness?
Directly. ISO 45001, ISO 9001 and ISO 14001 each require specific types of evidence, and if the module covering that evidence type is absent or misconfigured, you will have a gap in your audit trail. Incident investigation records, corrective action ownership and closure, and documented audit findings are typical of what an auditor may check. A module that is switched on but not embedded in daily workflow produces incomplete records, which is nearly as problematic as no module at all.
What if our team is already using Donesafe but we think we have the wrong modules?
A system review is a sensible first step. KIS Group lists a system review among its services for clients already running Donesafe, alongside adding standard modules and building custom ones, and a review is a way to look at where modules may be missing, misconfigured or underused.
Sources
This article draws on the following pages.