Not all users are created the same. Some are standard, some are admins, some are arrows or paper planes.
Look at the picture in the header:
- the woman represents the “standard user” looking at charts she has access to according to her user credentials (in an application with workflows, you will also find variations based on role, such as “approver” or “assignee”);
- the cogs behind the screen represent the “admins”, with universal access to the stuff behind the scenes;
- next, the “arrows” and “paper planes” (disclaimer: I made up these definitions based on the picture): in my mind, they represent that community of people that don’t actively use the system but may be the initiators or the targets of information exchanges.
This post focuses on the last point, a peculiar class of peripheral, “shadow” users.
Arrows
Imagine an issue management process: there will be one or more dedicated teams in charge of cataloguing and organising the issues and managing their lifecycle to resolution. These will be the “standard” users of the system.
However, where do the issues come from?
Typically from a general audience where anyone may report an “alert” (the seedling of an issue). Unless we are dealing with high-volume, specific operational processes with highly targeted audiences, the individual raising the alert may only do it very occasionally and will not be interested in using the system other than “shooting” their observations and getting a notification that the alert is being appropriately handled and eventually closed.
In other words, guaranteed delivery without having to sign-up to and learn yet another app.
Paper Planes
A mirror-version of the above: an active system user, say the issue manager, wants to notify someone about a particular issue and the receiver needs to get the message without having to know anything about the system.
It’s easy to recognise this kind of interactions on CRM systems: emails are sent out to prospects and each exchange ends up in a well-organised database.
The security challenge
When a user is only peripherally and occasionally involved in data collaboration, Security needs particular attention.
The challenge is to ensure identification and secure information transmission whilst minimising/hiding the burden of interacting with a system.
In other words, seamless login and message encryption.
Within a company, seamless login is best done via a Single Sign-On (SSO) framework, which allows any employee to gain access to any internal system appropriately “wired” to SSO.
A sub-optimal but viable alternative is email when complemented by walled gardens (e.g.: IP restrictions) and Transport Layer Security (TLS) encryption.
Finally, when dealing with the external world, there is the additional challenge of spam attacks (hence those annoying but necessary CAPTCHA widgets).
The administration challenge
The most secure environment in the one with precise, known boundaries.
With this in mind, you may limit the “shooting of arrows” and the “launching of paper planes” to users that have been explicitly added into the system by an admin team.
This approach, however, creates an administration burden that cannot be realistically handled manually (unless numbers are very low), as well as headaches such as “how long after inactivity should we deny access to x or y?”.
The administration of access and credentials of “shadow” users is best handled automatically according to well-defined rules, removing the need for manual intervention.
LiveDataset
When choosing a data collaboration platform it is important to know your audience and verify that it can participate in the correct way within secure boundaries, even when usage is peripheral.
LiveDataset, designed to make business processes easier in a corporate environment, supports authentication via OAUTH2 (OpenID Connect) SSO protocols, the passing of credentials via SCIM, as well as email TLS encryption.
Additionally, our experienced team will be able to create tailored, secure alternatives in those contexts where these standards are not supported.