Donesafe News

New Dashboard Filter! Placeholder Text! New Incident Wizard! More things too!

By | Donesafe Product Updates | No Comments

Dev Blog May 2017

This month had a bunch of great upgrades and a lot of work going into meeting some newer requirements for the automations system. There’s also so some important update notices in here so Read On!

New Dashboard Filter tool with save function

You all will have noticed this nice new filter feature appear about half-way through the month.

The dashboard filter tool is designed to help different of levels of user get to the types of information they’d like to see on their dashboard. For example, a standard employee is likely only interested in their own actions and records, whereas a team leader will be interested in their team’s open actions and records.

The dashboard filter allows users to filter down to what is relevant to them, and then use the save tool to lock the dashboard view in place as their default view.

With the removal of the location filter last month, and with a much wider, more diverse group of users using Donesafe than when this dashboard was first designed, we decided that this level of control was the first step in allowing users to see the information they need to see in order to best do theirs jobs.

If you need any clarification on how the filter works and how to use it, you can click here to read some help documentation.

New front end User Directory

We’ve been teasing this one for a while, and though it’s still in its infancy, it’s already getting some nice use. Through the ‘Monitor’ section, you’ll now see a new report: ‘User Directory’.

This report shows basic contact details for all users in your location and is part of the larger ‘Emergency Management’ upgrade in Donesafe. As I’ve said, it’s still in its infancy, but as you can see from the screenshot, you can filter and sort by location, organisation and even tags if for example, you’re trying to contact your Fire Wardens. You will also be able to see users outside of your location also. To do this, click on the locations filter and change to ‘All’.

The same applies to location and tags.

There’s likely going to be some more activity in this area in the coming months so, as they say, watch this space.

To learn how to enable this feature for your role, click here.

Acknowledgement Report Upgrade

It’s been a while since the ol’ acknowledgement report got any love, and in that time we got a good chunk of feedback about what we did wrong when we first built it. Here’s the upgrades:

Now only displays ‘Acknowledgable’ KB articles in the article list.
This was an obvious one; rather than show every single KB article in the list, it now only displays the ones that are acknowledgeable which makes it muuuuch easier to stay on top of everything.

Fixed position top and left headers.
This one wasn’t a problem for businesses with not that many employees and not that many knowledge base articles, but trying to figure out who had acknowledged what on the old report was actually a bit of a pain. Now both the KB article title and the users’ names are housed in fixed position so you can scroll around the acknowledgement matrix and easily see who has acknowledged what.

Vertical column lines
Not a big change by any means, but it makes it just that much easier to process what you’re looking at.

One thing; since the locations security update we’ve had a couple of users reporting that they can’t pick any users on the Acknowledgement report. Don’t worry; it’s actually doing what it’s supposed to- your users need a home location in order to be found in that report. Here’s a help article on it.

Knowledgebase section update

There were two noteable updates to the knowledgebase this month, both off the back of some user requests (so keep ‘em coming!).

Location selector added to Knowledge Base Index.
After the top menu location selector was removed, there was, for a time, no way to filter Knowledge Base Articles by location. This caused a lot of users trouble- so we thank you for your patience with this. You can now filter by location from the drop box on the index. The delay in resolving this was due to Knowledge Base articles having multiple locations as opposed to other records having just one. To resolve this, if a KB article has more than one location, the location column will display the location as ‘Multiple’. If you then apply a location filter and that article appears in that location, the selected location will display in that column.Also, as a result of the location security update, knowledge base articles in locations that you don’t have access to will no longer show up in the KB index- another thing that was a very common request.
Knowledge Base Articles now display with Workflow, location and area information.
Back when the workflow window was updated, the knowledge base was overlooked for this update and actually lost some features at the time. It has now been added along with a full location and area list.

New Incident Wizard

We’d started getting some feedback around businesses wanting more detail captured during an initial incident report. Rather than expand the incident form however, we’ve introduced a new system which allows you to configure your incident report form to include the ‘Add Incident Participant’ and even ‘Answer Template’ sections as part of a reporting wizard.

To reiterate; this is a configurable system so there’s no need to implement if it doesn’t suit your business’ processes. However if you DO want more detail captured at the beginning of a report, this is a fantastic and very malleable way of doing so.

Part of the incident reporting feedback we’d received was also around making sure, not only that admins could choose the order of requested details, but also, have control over who sees the additional forms and under what circumstances.

For example, using the wizard builder, you can now offer up a specific incident template if the incident was recorded as a ‘Safety’ incident or a different template if it’s a ‘Quality’ incident. AND you can also have the option of showing that only to users who meet certain criteria, such as, their role must be ‘Manager’.

If you set it up and how you set it up is entirely up to you; the system was designed to be as malleable as possible in order to meet the needs of a wide range of businesses, without impacting those who choose not to use it.

If you’d like a demo of what it does and to learn how to set it up along with some of the trickier configurations, click here for a tutorial.

Incident Types and Hazard Types overhaul (with important stuff)

Last month we wrote about about Incident Types getting an overhaul. Now, Hazard Types have gotten the same treatment. As with incident types, you can now go as many deep as you want with Hazard sub-types. The incident type update was recorded here, which covers the guts of how it works with hazard types, but a few more updates were made this month to improve some systems around this upgrade.

Rule builder settings for Automations, Workflows etc.
Since switching to this new system, automations and workflows related to incident and hazard types had developed a problem. To illustrate this, in the past, if you’d wanted an automation to trigger if an incident type was equal to Health, you’d use a rule like this:
But since the update, the type is essentially recorded as the lowest possible type in the type list which resulted in some automations not firing. To resolve this, a new rule was added: ‘Parent of Type’. This essentially means that if you want a rule to specify the parent type (as in, the top level of types for incidents or hazard), instead of picking ‘Type’ as the option, choose ‘Parent of Type’. This means that no matter what is picked below that level, if it’s parent is ‘Health’, then this will meet the rule.
Reporting for Incident or Hazard Types
As with the rule builder, because the nature of what is considered a type changed, it caused some issues in reporting. This has been addressed by including the full detail of the type in the ‘Type’ list including all of the selected type’s parents.

Set your own Plural names for modules

It’s a little one, but a good one. In the past, if you named a module, Donesafe would have a crack at naming the plural of that module for you and to be honest, we weren’t always good at it which lead to some silly situations. (No Donesafe, the plural of ‘Competency’ isn’t ‘Competencys’). So now you can add your own.

Just go to Settings > Modules then select the module you’d like to edit and go to the edit menu. You’ll see a new setting there: ‘Plural Display Name’. It’s a simple, but effective tweak that arose of a common complaint.

Login email addresses are no longer case sensitive.

… let’s be honest, we probably should have fixed that ages ago. Hopefully this resolves some of your access issues though. Enjoy!

Locations Update (continued)

Last month we reported a big update to location security (which you can read about here). This clamping down on location security however brought up some bugs which our older ‘spongier’ rules managed to avoid. To fix this, we made some changes to locations in the admin section which also have the added bonus of fixing some older issues.

Home Locations are now mandatory for users.
Because a LOT of view rights are governed by locations, users without ‘Home Locations’ were having trouble with their access. To resolve this, the ‘Home Location’ field is now mandatory and if you save a new user without a home location they’ll be automatically added to your lowest active location in your location list.

Locations can no longer be deleted- Only Archived
Sounds silly right? But what if you delete a location that has an incident attached to it, then try to edit that record and all of a sudden can’t save it to the location where the incident actually happened. Not so silly now eh? This issue of missing locations had been an ongoing one, so we’ve removed the ability to delete a location and made them ‘Archive Only’.

Archived Locations now show up in the ‘Active Locations’ list in user profiles.
Just because a location is archived, doesn’t mean you don’t want to be able to access records in those locations. Now, when you archive a location, users don’t immediately lose their rights to see records they may have created in that location. To help you identify the archived locations in that list, they’ll simply have (Archived) after the name.

There were a couple of other tweaks, but those are the main ones. Let us know if you think we missed anything.

New Automation and Actions Tools!

Automations got a bunch of really nice upgrades this month to help you streamline your processes, better target your users and even personalise your messaging. To find out more, read on…

New Tutorials (finally) available

So it’s been a few months since the major overhaul of workflows and the introduction of the new automations tool. I’m the first to admit that we’ve been dragging out feet on new tutorial materials; partly because those systems were still settling in and partly because we’ve been so busy! Now though we’re ready to flood you with new articles and tutorial videos. Here’s some of the newest stuff:

All of these tutorials are on the more advanced side of Donesafe’s automations so take your time, get comfortable and see how you go! If you think we need more materials, don’t hesitate to reach out to support. Regular requests or even good ideas for support articles do get listened to and you might find that you suggest something and a day later it appears in the help section – so don’t be shy! Request away!

Placeholder text for personalisation of automated actions and notifications

For the automators out there, this is one of the most exciting upgrades to the automations system this month, so rather than make you wait for it, let’s be greedy and jump right in.

You can now use placeholder text in your automated actions and notifications to include information from the record. This means that instead of an automated action that says…

… you can have…

Cool right? At first it seems like just a nice change, but in terms of streamlining workflow it can have a huge effect. For example, rather than receiving an email that a team member was injured then having to log into donesafe to get the details, you can now opt to see the basic details in your email immediately, enabling you to quickly complete your action on the spot.

It has other huge advantages as well. If for example, a team member’s document is expiring, in the past you could have set up automations to receive…

…which didn’t tell who’s document was expiring, or what the document was, so it was effectively useless. Instead, with new placeholder text, you can set up automations to say:

As you can probably tell, we love this new feature. The best thing about it is that it’s really easy to use. When choosing your text for an automation simply type the @ symbol to bring up a list of available options, select one and away you go. Here’s a tasty GIF to demonstrate.

And that’s it, a tiny change with YUGE implications. That’s what we like.

For more instructions you can click here for an easy tutorial and troubleshooting.

Quick User Collections PLUS Added new ‘Dynamic’ user collections to automations (if you use automations this is awesome).

Disclaimer: this is an advanced feature.
This feature is for more advanced account setups; but it solves a major problem with User Collections that some accounts were having. User collections are a super malleable way of passively grouping users for use throughout Donesafe. When it came to Automations however, it wasn’t able to take a dynamic view of users based on the location of the record.

Well, you can now target your automations to a dynamic group of users based on the location of the record.

Let’s say an incident occurred in Wellington and you wanted to be able to notify all user/s with the Role ‘Team Supervisor’ in Wellington specifically to send them an action or bring them into the record.

To do this in automations, when you’re setting your ‘For Every’ field, right down the bottom, select, ‘Quick User Collection’. This will bring a user collection rule set into your active window.

Then, choose the following rules:

[Role] [Equal] [role name].

AND

[Active Locations] [Contains] [Record’s Location]

This user collection will now target all users with the role ‘Team Supervisors’ in the location of the incident. In the past to get this working for all your locations, it would have been different automations for each location. Now you can do it in one.

PLUS, if you’re using the super cool new tagging system, you can refine this even more to very specific users based on your tag setup using a collection like this:

Again, this is a more advanced feature, but golly, the possibilities for automations are truly awesome.

You can read some tutorial detail on it here if you need to. Here’s a standalone article that discusses targeting a tag’s location also.

Action notification emails now link directly to the action

This one’s little but mighty handy. On all action notification emails from donesafe, you’ll now also see a link that takes you right to that action on the actions screen. This will help you quickly close off simple actions as they come up. Anything to help with action management right?

New Add Incident Participant Automations for incidents!

We’ve been hanging out for this for a while. It’s been an ongoing request for users to have more control over how and when users are being automatically added as involved into incidents. (example: when a worker is injured, their manager is automatically added as an investigator). That control is now yours to wield!

In incident automations you’ll see a new option under the ‘Create a new’ title: “Incident Participant”

Selecting this when building your automation will mean that as the result of your rules being met you can now add an incident participant to an incident. For example, let’s say that if you have a safety incident, you’d like to not only notify, but automatically add the team supervisor in your location as an investigator to the incident, you can do that using this new tool (combined with new Quick user Selection tool) Nifty hey?

Want to learn how to do that? Just click here for a quick tutorial.

Trigger automations when a person affected is added under specific circumstances

This one’s an awesome new feature. In the feature above I mentioned that you can add an incident participant – as a result of adding an incident participant. I kinda glossed over it there, but it’s actually a fantastic upgrade.

This allows you to target very specific situations with your incident participant automations. Before you could only trigger automations for an undefined number of incident participants. Now though, if I wanted to, I could configure automations to fire when a person is added as a ‘Person Affected’ AND they lose time as a result of this, but ONLY if there’s a high risk of it occurring again.

It’s a super powerful feature and if you’d like to learn how to use it, click here for a quick tutorial.

Old hard coded incident rules replaced with configurable automations.

This was a long time coming. We’ve a had a lot of people wanting to be able to configure the old hard coded incident automations. Back in the day, if you were added as a person affected in an incident, your manager WOULD be added as an investigator and there was nothing you could do to turn that off or to have it behave differently. Now, with the new automation tools listed above, we’ve finally reached a point where you can.

Before you panic, don’t worry, the old behaviour is still there, only instead of being hidden behind a wall of code, you can now see them happily nested in your automations section under the incidents tab. You’ll see three new automations there marked as (System) automations.

You can turn them off, edit them; it’s totally up to you.

The only real behavioural change you’ll see is a really good one: You can no longer add duplicate Incident Participants. SO, that means, you can’t add the same person as an investigator twice. This was a major pain point for heavy users in the past where they had some managers getting spammed by ‘Automatically assigned as an investigator’ emails as they were added to the same incident multiple times. This can no longer happen thanks to this glorious tweak.

Changed the name of ‘Call To Action’ links in automations to ‘Custom Links’.

… because nobody knew what a ‘Call To Action’ link was supposed to be. Literally, it’s a custom link; so we’ve now called it that. It’s a minor thing, just wanted to mention it.

Psst. This custom link feature is becoming super useful now in automations. It allows you to send a custom link to anything along with or instead of a link to a record. Don’t be shy, have a play!

Is that it? Not at all!

Since updates are coming so quickly and consistently now, rather than list every update in a blog article, instead we’ve set up a new Update Logs section in Donesafe help. We update these logs once a week so if you need to check any recent changes you can do so there. These changes include new features as well as new bugs so it’s always worth a look.

To see the full list of updates for May, click here!

Of course, if you have any questions about any of those items, don’t hesitate to reach out, either by commenting here or reaching out to support.

Until next time; stay safe out there!

Want to keep up with the latest updates as they happen? Sign up here.

Cancel Reply

You must be logged in to post a comment.