Chaser deliverability

The new chaser feature of agileBase is proving one of the most popular things we’ve ever launched! For users of our agile:SA product, chasers are set up for you to automatically email suppliers requesting new ingredient spec documents, non-conformance responses, certifications & accreditations, risk assessments etc. whenever they’re due.

chaser example

With the gradually increasing focus on compliance in the industry, this innovative feature helps you maintain the best quality and grades, whilst enabling your NPD teams to launch new recipes faster, due to slashed paperwork times.

Today we’re releasing an update giving you the ability to have these emails sent from your own domain name, should you wish to.

By default, emails come from @agilechilli.com, our domain name – we can’t send email from a customer domain name without agreement and setting it up securely. That process is now in place, allowing our software, with your permission, to send emails to your suppliers and other contacts from your own domain name. You can choose whichever email address you like for emails to come from, even different addresses for different types of chaser.

The system we use also brings enhanced deliverability – we use a service with enhanced reputation, monitoring and virus scanning, which receivers trust, lowering the probability your messages will disappear into spam bins. To ensure security, various technical measures like SSL, DKIM and domain validation are in place, as well as regular scanning by TrustWave.

The cost for this is just a one-off setup fee of £75, then £15 added to your monthly bill. That will allow up to 1000 messages per month to be sent. If you need more, 3000 can be sent for £25 per month.

To get this set up, please request this to support@agilechilli.com. We will need to liaise with you and/or your IT suppliers in order to configure your internet domain name to allow this service to run.

Advertisements

Sensitive data and personal data

If you store records of people you deal with in your agileBase instance, what is that data used for? Where did it come from? Who can see it? Why is it legitimate for you to process that data – which of the six lawful bases under the GDPR apply? Will the data be accessed outside of the country? How long will it be retained for once it’s no longer in use?

As you are no doubt aware, the General Data Protection Regulation will be applicable as of May 25th. Most companies using agileBase store some personal information so these questions and others are all things that need thought.

A lot of other data may also be commercially sensitive too (rather than personal data), requiring just as much careful thought into data protection.

Data exports

This week’s update is relevant in a couple of ways. Firstly, additional measures are in place to protect against or mitigate the unauthorised mass downloading or exporting of data, working in concert with the existing safeguards. Remember that the export option is only available if

  1. the user is a member of a role which has ‘allow exports’ ticked (off by default)
  2. the view has ‘allow users to export’ ticked (on by default, can be disabled in the view’s manage tab)

Now, even if an export is allowed, an administrator can choose to get notifications whenever an export over a certain size occurs. This option is triggered if the administrator ticks one of two boxes in a table’s ‘manage’ tab:

  • this table contains personal data
  • this table contains commercially sensitive data

personal and commercially sensitive data

When either of those are chosen, the admin will be prompted to choose a number (defaulting to 100). Any exports containing at least this number of records will prompt an automated email, which they can use when checking if the export is for a valid reason.

When managing one of these tables, the administrator is also shown which roles have the ‘allow exports’ option and whether any views are set up to transfer data to third party systems using the API.

Data protections and the GDPR

If the admin selects ‘this table contains personal data’, then a further section of notes is displayed, prompting consideration of various data protection questions pertinent to the GDPR. There are even some boxes where you can record your thoughts about each issue, current situation, future plans or whatever else is useful to you.

Please bear in mind that this is not a tool to manage your company’s evidencing of compliance with the GDPR. Hopefully though it will be of some practical help, particularly prompting you to think about data privacy and protection from the moment that a table is first created. For a system such as agileBase, where agility is a key feature, allowing systems to be built and evolved rapidly, it’s important not to overlook that!

If you need some help checking preparations for the GDPR, there’s some really good background information on the Information Commissioner’s Office website and there’s a fully indexed, searchable version of the entire regulation at https://gdpr-info.eu.

 

 

 

Text message number change

A quick  update – customers may notice that the number that two factor authentication codes come from has changed. That’s because the old number only had capabilities to send within the UK, the new number can send worldwide, which is necessary for some of our customers.

The new number is +447400094002, you may like to add that to your phone’s contact list so it appears with a friendly name when you receive a message.

We encourage everyone to enable two factor authentication – it makes your account more secure. To do so, simple click your user icon at the top right of the page, select ‘edit profile’ then type in your phone number. Note landlines won’t work, it has to be a mobile  phone that can receive SMS text messages.

phone number entry

agileBase automatically checks whether your password has been leaked

login

One of these days, we won’t need to remember passwords, everyone be able to quickly and easily log in to services with biometrics (e.g. face recognition, voice recognition, even heart rate recognition), USB keys or perhaps chips in our phones/watches/jewellery or embedded under our skin!

Until then, we have to manage our passwords. The problems are many – these days, short or simple passwords don’t cut it. They’ll be easily ‘brute-forced’ by attackers, trying millions of passwords per second. So, we have to remember a long and complex password. However, not just one, these days a typical person will log in to at least dozens of websites, apps and services. Using the same password for all of them is a bad idea.

Currently, the best solution is to use a password manager. We use 1Password here at agileChilli but there are others available.

One thing you may or may not know is that if a service’s passwords (or password ‘hashes’) are stolen, they will often be published on the internet by hackers for everyone to see. That’s what happened recently to companies like Adobe and LinkedIn. In other words, if you use a password for services A, B, C and D and user details are hacked for service A, someone can often look up those details and use the same ones to log in under your name, to B, C and D too!

Luckily, hackers aren’t the only ones who can look up lists of stolen credentials. Troy Hunt, a Microsoft Regional Director and MVP, has performed a great public service by creating an easy to use tool for checking a password against a massive list of previous data breaches.

We have now integrated with that service (which you can try yourself manually at https://haveibeenpwned.com/Passwords). Whenever you try to set a password in agileBase, it will first look it up to see if it’s previously occurred in a data breach and if so, it won’t let you use that one. That either means your password has been previously stolen, or you’re using the same password as someone else who’s had it stolen, in which case it probably isn’t a very good one. Either way, you definitely shouldn’t use it and if you use that password for any other services, you should  change it immediately.

By the way, when checking, the password you type isn’t actually sent to the third party service in ‘plain text’, it’s all managed securely. 1Password were one of the first organisations to take advantage of the new version of the service a couple of days ago. If you’d like more information on how it works, their blog post is a good read.

Now we’re pleased to follow suit and announce our integration with this valuable service.

HTTPS everywhere

Whilst we’re on the subject of data security, another recent update has been to our public website, www.agilechilli.com. SSL encryption is now used for the whole site.

SSL has always been used for the agileBase platform itself, not just while sending your login credentials, but for all data transferred during use. However, the entire public website (our product info, case studies, pricing etc.) is now encrypted too. For some information on why this is a good idea, please take a look at https://doesmysiteneedhttps.com/

Thank you to CloudFlare for making this a really easy thing to set up.  If your own company’s website doesn’t yet use SSL (HTTPS), then we encourage you to suggest it to your web or IT staff.

Reporting file storage

A quick tip for people uploading files to agileBase – if you hover over a filename or icon, the file size will be displayed. The size shown is a total that includes all previous versions, if you’ve uploaded multiple versions over time.

There’s also a new ‘hidden’ field available that can be added to views, ‘storage used (MB)’ which shows the total size of all files uploaded to a particular record. Using that, the total storage used for all files can be displayed. Plus any of the standard agileBase features such as filtering and charting can be used to break down or analyse usage.

doc sizes

Thanks to Britannia Windows and Foodcase International who both (independently) suggested this feature.

GDPR – what it means to us, and you

Any organisation using the agileBase platform will almost certainly be storing and manipulating data, whether that be as one of the agileChilli standard apps for food manufacturers, or a custom system tailored to your industry and organisation. That data might be sensitive and will in some cases be personal data – data about individual people.

If that’s the case you’ll more than likely know all about the General Data Protection Regulation (GDPR) which comes into force this May. Even if your organisation doesn’t hold any personal data this article may still be of some use. Virtually all organisations have important data they need to secure, it may be just be important and sensitive in other ways.

To that end, we’re publishing the outlines of the processes we follow. You may like to adapt some for your own use or just have a read to see if there’s anything you’d like to investigate further.

Secondly, as a supplier of a platform for ‘business agility through technology’, we’re in a rather unique position. Under the GDPR, we will be jointly responsible with our customers for ensuring personal data in the system is protected. To do that we need to know what type of data it is, where it’s stored and what it’s used for. However, because our customers often build and improve systems on agileBase entirely on their own, we don’t always know the answers to those questions. Therefore, we will be contacting some customers with a ‘screening questionnaire’ shortly, to help us ascertain whether further discussions or audits might be appropriate.

Our framework

GDPR_Cyber_and_Data_Security_Framework

We designed the Compliance Cycle model above to help us understand the scope of the new GDPR by offering a high level overview of our approach, based around eight core themes.

Of course, many of the details, practices and technologies will be the same as those we carry out anyway as good practice in protecting customer data generally, which we’ve always taken very seriously. The main difference is that we now have to ensure customers understand both their own obligations and the measures we take, so that they can be confident of their own compliance.

Step 1) Learn and Educate: As a SaaS provide we need to educate both ourselves and our customers about the impact of this regulation on our respective businesses. In particular, we both need to understand what constitutes “personal data” and “sensitive personal data”.

https://www.burges-salmon.com/news-and-insight/legal-updates/gdpr-personal-data-and-sensitive-personal-data/

Like many customers, we store staff training records in agileBase, including induction records detailing steps taken to help them manage data securely during the course of their work

Step 2) Identify: Once we understand what data is being collected we need to identify where this is being held. From a software perspective we also need to know where it flows to and from.

Examples might be data flowing into agileBase from e-commerce websites or out to finance packages via the API (a system for connecting software).

Step 3) Minimise: The first step in this process is to consider deleting any old data that is either of a high risk or of low value, but no longer of any real use. Secondly, consolidate (move) personal data from difficult to monitor tools, (e.g. spreadsheets) to systems that lend themselves to central control.

As a SaaS provider we will also need to minimize any risk our clients may expose us to.

Step 4) Assess: We then need to assess the overall level of residual risk by considering both the inherent risk in each type of data held and the specific risk for this type of data in each of the locations in which it is being held.

Once we know our risk exposure we can decide how best to manage that risk.

Step 5) Protect: We then need to work to secure the data we retain, with a particular focus on high risk personal data.

Step 6) Monitor: We need to put in place systems to monitor activity that might require investigation and have in place policies to rapidly address genuine issues, breaches etc.

Having done our best to reduce any ‘business as usual’ risk to a reasonable level we now need to plan for how we will handle any failure.

Step 7) Respond: We need to be ready to rapidly respond to both day to day queries about the data we retain from various stakeholders within the time guidelines laid down within the regulations and to any breakdown in our data security measures.

Response templates will be stored in our agileBase document library for centralised and easy access, together with stakeholder contact details

Step 8) Report: We also need to have procedures in place to report not only breaches failures but also an unusual activity, to the relevant authorities and customers.

Further details

Any customers who would like details on the technical and process steps we take to protect data should contact us at support@agilechilli.com. If you’d like to hear about setting up document libraries for forms and procedures, training records or asset/systems inventory databases, please do get in touch too.

As always, we look forward to hearing from you.

Sub-recipes

Our NPDtech product for food manufacturers has a new ability – rolling up all the ingredients in a sub-recipe to form an accumulated ingredients declaration.

Note: while this example deals with recipes, the agileBase platform can use the same features to work with any items that require a rollup e.g a bill of materials (BOM).

Take a simple example – a recipe for beef pie. The ingredients might be entered as follows:

beef pie ing

making the ingredients declaration

Rump Steak (46.4%), Stock (29.4%), ShortCrust Pastry (11.6%), Onion (10.3%), Olive Oil (0.77%), Salt (0.52%), Black Pepper (0.41%), Thyme, Parsley

However, shortcrust pastry is itself a recipe with ingredients

Flour (57.3%), Butter (25.2%), Water (16.1%), Salt (1.38%)

We now have the option to roll up the ingredients from this sub-recipe into the top level ingredients declaration, creating

Rump Steak (46.4%), Stock (29.4%), Onion (10.3%), Flour (6.7%), Butter (2.9%), Water (1.86%), Olive Oil (0.77%), Salt (0.68%), Black Pepper (0.41%), Thyme, Parsley

As you can see the additional ingredients salt, butter, water and flour are now included with the correct percentages of the total recipe.

The great thing about this is that it will work with not just one level of sub-recipe but the sub-recipes themselves can have sub-recipes and so on to any depth.

When generating this ingredients declaration, the system gives you the option of starting with either the top level or full ‘rolled up’ version. Following that, it can be manually tweaked as required. Another nice addition is that you can now specify a percentage level below which no percentages will be output – in the above example, it’s set at 0.3%, meaning the herbs percentages aren’t shown.

What’s more, when editing a recipe, a tab alongside ‘ingredients’ shows you which product each sub-ingredient comes from, along with the countries of origin.

exploded

A major benefit is the fact that you can search the system for any ingredient and immediately see which recipes contain it, even if the connection isn’t direct. That could be very useful if any ingredient alerts (those from the FSA are displayed in the system) or recalls are required.

For anyone interested in the technicalities of how this rollup works behind the scenes, it utilises agileBase’s ‘recursive workflow‘ feature, which we wrote about back in July.