Entering time durations

A very quick update on a new feature for the agileBase platform: if you have a field which is a time duration, it can now be entered in hh:mm format. This can be useful for applications like time logging.

To set this up, create a decimal number field to use as the time duration. Edit the options and tick ‘use duration’.

In the user interface, people will see an hh:mm data entry box. However when data is saved, it will be stored in the database as a decimal number representing fractions of an hour. So for example


will be transformed into 1.5 i.e. one and a half hours. That means reporting, charting and data analytics can all be used to total up time.

We hope this is useful to you and look forward to hearing your comments.


Visualising workflows

We love it when customers push the boundaries of the agileBase platform. There are always new ideas to explore.

Our latest update was inspired by a couple of customers who’ve built a lot of process automation using the agileBase workflow engine. They want to take things even further but are starting to see the need for a map of all existing workflows so they can see everything in context and check the order in which things run.

One customer has close to 150 workflow automations so being able to manage them all in one place is highly appreciated.

We’re pleased to announce a new element of the agileBase usage dashboard – Scheduled Workflows. To see this, click the bird icon at the top left of the homepage and select ‘usage dashboard’. Then just scroll down past the first few metric visualisations.

The screen shows workflows categorised by when they run – every 5 minutes, 10 minutes etc. up to daily at times you specify.

Workflow chains are marked out – that’s when a workflow has multiple linked steps, for example generating an invoice PDF then emailing it to a customer.

The icon for each workflow shows what type it is, e.g. a Chaser for sending emails and gathering feedback, a workflow to create new records or a document generator.

Workflows which are currently scheduled show a green icon – hovering over it shows the time it’s scheduled for.

Finally if any errors occur, the workflow is highlighted in red with an error description.

Clicking on any workflow will take you to it in the admin interface where you can edit its details.

Rules for deleting data

You may know that you can set up various policies for how data deletion in agileBase works:


The default and most restrictive (safest!) is that if there are any records linked to the one you’re deleting, you won’t be able to remove it until you’ve manually removed or disassociated all of the linked ones too.

That’s great for protecting important data but can make things tricky when just testing things out as a new user, demonstrating to colleagues etc., particularly when automated workflows are involved. If when you create an organisation record in a CRM system, a default site and a couple of other related bits of information are added automatically, deleting a temporary record can be quite a chore. How can we address that?

One idea we’ve introduced recently is to allow a ‘grace period’ of an hour before the more stringent deletion policies come into effect. In other words, if you create a new record, you can delete it and all it’s dependencies with one click within sixty minutes of the creation time. Only after that do the restrictions come into force.

That’s useful for users and important to know for administrators. If as an administrator you have any questions or you’d like to customise this, please get in touch with us.

Content Security Policy

Today’s update is about something that you as a user will probably never notice and wouldn’t have known about if it wasn’t for this post. There are no new features, behavioural or graphical changes.

However it is something we’ve deemed so important that it’s been worth spending the past year on. Work started in March 2018 and has just been completed.

So what is it? In a word, a Content Security Policy (CSP) has been implemented for the agileBase web app. In plain English, that’s a security mechanism that, when someone’s logged in, prevents unwanted code from running. Only specific places, like our own server and a couple of whitelisted services we use (e.g. Google to display maps) are allowed to serve code to the browser. This protects user data against a number of possible attacks.

If you want a fuller technical explanation Scott Helme has a good intro here:


and Google explain well why CSPs are so important:


CSPs aren’t yet widely used on the general web – in 2018, only three to four percent of the Alexa top 100 websites had a policy enabled. Why’s that? Simply put, it’s often a lot of work to back-fill support into existing sites. A lot of low level things need to be changed – the larger and more complex the system, the more there is to do. On ours there were many hundreds of tweaks necessary, many straightforward but some complex to deal with.

Now it’s live though, we’re very happy to be an early adopter in the knowledge that customer data remains protected using the latest standards and tools.

However, we never rest on our laurels, we’ll be continuing to push data security and privacy by encouraging more use of Two-Factor Authentication by users as well as other measures you may hear about on this blog in future!

Roundup – What’s New

What’s new in the agileBase platform this week? As usual, we haven’t been sitting on our hands and there are some interesting new updates.

Font Awesome

The icons used in agileBase, as part of the user interface and from which an administrator to represent each tile, have been upgraded to Font Awesome version 5, bringing a massive number of extra icons and a fresh, clean look, as well as some usability enhancements – ticked checkboxes are easier to differentiate.

We are a proud funder of the Font Awesome 5 Kickstarter, the most funded software Kickstarter of all time. As such we’re able to make over a thousand icons available in agileBase including the Pro pack – whatever module or app you want to build, there’ll be an icon for it!


Some customers use the multi-tenanting capabilities of agileBase – the ability to separate users into groups who can’t see each other’s data. This can be used for example to allow different sets of companies, clubs, or membership groups (or whatever the organisational group is) to use the same system features whilst remaining separate from each other.

To recap, the way this is set up is that a role is created for each group with a ‘filtering’ field name and value. Whenever a view contains a field with that name, each user will only see rows where the value matches the value of the role they’re in. If a view doesn’t contain that field, data is visible to all users, which may be what’s required in some situations, for example where there’s a shared dataset such as a collection of help articles.

Now, views without a filtering field will be highlighted in the admin interface in red. So an admin can see at a glance which views will be filtered, which should help stop any from falling through the cracks.

Multi-tenanted Audit Trails

A second enhancement to do with multi-tenanting is that all audit trail logs now include the multi-tenanting value for the role a user’s in. That means an administrator can easily compare usage for each group, or even give access to the audit trails to each group so they can see their own use.

Revolutionary Speed Increases

The agileBase strapline is ‘fast, friendly, flexible’. By ‘fast’ we usually mean fast to develop and prototype, i.e. you can typically get working business databases built and running in minutes or hours.

However, it has another meaning too – we’ve always strived to have the fastest response times as users interact with apps built on the platform. That’s down the the many optimisations we build in to both the server and user interface – too many to list here – as well as the choice of technology (props to PostgreSQL, the world’s most advanced open source database) and high performance hosting (thanks Linode).

As the number of customers grows and the sizes of their systems balloon, we need to always bear performance in mind.

Today we’re excited to announce the most effective single change we’ve ever made to improve performance – the ability to use caching on high transaction rate views.

Caching in general has been an option for a while (materialization in database terminology). When you have complex views that are slow to query, but don’t update that much, it’s great. A common example would be a financial report totalling up sales per month. There may be millions of rows of data involved. Caching can make querying, filtering and charting much more responsive, so data loads in milliseconds rather than seconds.

To date, the options have been to update the cache every 10 minutes or once a day, which is fine for those sorts of views where new data isn’t added that often.

However, what about views which are complex, perhaps with many calculations and lots of data, but which are also updated and used very frequently? Stock figures, sales jobs or orders for example. These are the ones which have most impact on people in day to day use, and on the system in general, which affects everyone.

The system will now update the cache whenever someone saves a new record, updates one or deletes one. This makes querying the data very fast. Typically, there are a lot more queries of data than there are edits, so the performance of the whole system is improved. For further efficiency, not every edit triggers a cache update, all changes are rolled up into one when the user moves from the editing screen back to the list of records.

What delay there is is also psychologically and practically in the right place. When users first open a tile to look at data, they want the response to be immediate. It’s important that searching for data is also very rapid. However, a short delay just after pressing save can be tolerable – the user has just finished doing something, as opposed to starting it. And of course the UI reacts immediately to let them know the system is ‘saving’.

Google has some good notes on the user perception of performance delays. As they say,

0 to 100ms: Respond to user actions within this time window and users feel like the result is immediate. Any longer, and the connection between action and reaction is broken.

We try to keep the data querying actions within this timeframe. Then

300 to 1000ms: Within this window, things feel part of a natural and continuous progression of tasks. For most users on the web, loading pages or changing views represents a task.

Reloading the list of data after a record save falls into this category.


Setting this up

As an administrator, if you have a view you’d like to speed up, how do you do so?

In the admin interface, just go to the manage tab for the view, click ‘advanced options’ and under ‘cache view rows’, select ‘cache view, update on record save’.

Welcome to a faster agileBase!

Mandating Two Factor Authentication

We’ve had two-factor authentication (2FA) capabilities for around three years now in the agileBase platform. Along with the other platform features, we’ve been keeping it up to date and improving as time goes on.

For example, as of a few months ago you can set up app-based 2FA for enhanced robustness.

Two factor authentication is now widely used in the world of software and generally understood by users, so we can start promoting it’s use a bit more. At the end of the day it is a practical security mechanism that for little effort can greatly reduce the chances of accounts being hacked. Everyone’s usually a fan of that. Find out more.

So the agileBase platform now requires that the most privileged actions require 2FA to be enabled. Those are

  1. Giving a user administrator privileges on the whole account
  2. Giving user manage privileges on a table

An administrator can effectively do anything within the customer account – add/remove users, assign roles and privileges and create/destroy any tables, views or data.

Someone with manage privileges on a table can make more limited changes to that table only but can still remove fields and delete/edit all data in bulk.

When an administrator assigns those privileges to someone, the system checks that the user has 2FA enabled first. If privileges are assigned to a role, everyone in that role must have 2FA enabled.

This is a step along the road to promoting 2FA throughout the user base. Please let us know if you’ve any thoughts or suggestions.