This week we release two major feature updates that improve data validation, both when entering new data manually and importing from spreadsheets.

Validation checks


As you may know, field properties give some control over the data that can be entered. For example, a field may be marked ‘unique’ to disallow duplicates, or the allowable options can be specified for dropdown and tag fields.

However, sometimes more custom validation rules may be needed, for example dates must be in a certain range, text must contain certain characters (as in the screenshot above), or a field may have a maximum length.

We’ve just added a ‘checks’ section into the properties for a table, where you can add these additional rules. Any type of rule that can be used as a view filter (dates newer or older than a certain number of days, field must or must not contain particular text with etc.), can also be used as a table check. Here’s where you enter them:


i.e. go to the manage tab for a table and use the new Checks section. There are a limited number of possible checks there to start with, but we’ll certainly be adding more and if there are any in particular you’d like to use, just let us know.

Spreadsheet import improvements

This is a simple update that much improves the usability of the import process. Rather than stopping at the first error encountered and reporting it, the system now gathers errors from all import lines (at least, up to the first thousand) and reports them all in one go.

No more fixing one error only to find many more on each separate import. You can now quickly get a good idea of how ‘dirty’ your data is at the start of the process.

Thanks to Jeff at Argenta for suggesting our newest feature – quick filtering of dropdowns and tag fields.


Here’s an example of filtering a list of expenses by category. Previously when filtering, you’d have to know what you were searching for. If you needed a reminder, you could of course hover over the column heading and you’d be shown a list/breakdown.

Now there’s a quicker way of filtering. Tickboxes automatically appear for the most popular items (up to 30). You can just tick the items you want to filter – tick multiple items to search for any of them.

Thanks also to @marriagebristol for help with a lot of other UI improvements released recently and in the pipeline. A couple to mention briefly are

  • double clicking on a row in a tab will now load that row full screen for editing
  • when a tab contains many rows, a search box will appear letting you quickly find records (suggested by Lewis Pies)




Administrators! If you’re not aware of our documentation, check out

A few pages have recently been added, notably how to set up company-wide variable fields (e.g. VAT rate), troubleshooting views/calculations and troubleshooting view cloning.

We’re aware there’s still a lot to do but it’s gradually getting more comprehensive.



… or at least interesting to look at.

agilebase usage

The above is an example of our newly updated administrator information page – it shows you information about what’s going on in your agileBase account: which parts are most used and by who, trends, capacity and usage etc.

The new addition is the graph at the bottom, which shows the structure of the database, how different parts of the system are connected together. This can be useful when bringing a new developer or admin onto a project for example, or for planning, to see where parts can be trimmed or added.

Sometimes when systems get really large, the graph can look a bit dense and confusing, with lots of interlinking lines crossing each other. To mitigate that, tables with the most connections are split out into their own little sub-graphs. In the example above, the ‘sales enquiries’ table has been split out into it’s own section, with connections to other parts cut. You can then easily see all the other tables that relate to sales enquiries, which would have been more difficult otherwise.

Credit to the Dracula Graph Library used to create this visualisation and if you’re interested in visualisations in general, check out


A while ago, we introduced the ability to better control deletion policies for data. To summarise, if you have two linked sets of data, say companies and contacts, where a contacts belong to companies, you can specify how you want deletions to behave. Either

  1. deleting a company will delete all related contacts
  2. deleting a company will cause contacts to be ‘un-linked’ and become orphans
  3. the system will refuse to delete a company that has linked contacts

Currently the default is 1: deleting a company will delete all related contacts – with suitable warnings of course.

However, having built up experience of how different customer accounts work, we now believe that 3 (refusing to delete) will be a better default, so we propose setting it to that for new relations and also making a one-off change across the board for all existing relations.

This decision has come from data about how customers actually use the system and because over recent years the types of data used in the apps running on agileBase have tended to migrate from the ‘business support’ end of the spectrum to the ‘mission critical’.

In many cases, users hold the very reasonable assumption that the system will protect them against disaster.

Previous work has simplified and clarified warnings, and okay-ing two prompts is necessary to carry out a deletion. Elevated privileges are also necessary to delete more than one record at once. However, from time to time, the odd mistaken deletion is still carried out. This is emphatically not the fault of the user – we’ve all been trained by a multitude of software apps to just click ‘ok’ whenever a prompt is offered without really spending time to read the message. I have myself lost a good handful of email drafts this way when closing them to read other messages for example.

It’s now up to systems to go the extra mile to build in protections against losing data.

That’s why we propose this across-the-board change. You know much better than us which parts of your system are the most important to keep safe. Changing settings per area is really easy for an admin to do, so by erring on the side of caution, we will enable the strongest protection of mission-critical data by default, whilst still letting admins tweak their own systems should users need to be able to make quicker and easier deletions of certain other data.

We’re not going to force this change on any customer though. If you’d like your system to remain as it is, that’s no problem – just contact us and we’ll exclude  the account from this change.

We’ll flick the switch in a week’s time – the week of the 5th of September, once all customers and partners have had a chance to understand what’s happening fully.


We should point out after the discussion above that a history is kept of all changes and of course data is backed up. However, restoring from a backup is a process that takes time and not losing data in the first place is optimal!

A major new feature has made it’s way into the agileBase user interface – the ability to bulk edit many records at once. Strictly speaking, this feature has been part of agileBase for a while, but previously it was only available in the administrative interface – now it’s available to the masses!

For example, if a field allowed you to select from a series of stages in a sales process and one of these options was “Qualified” and a decision was made to change the name of this stage to “Qualified Lead”, all the past records that had the value “Qualified” could be changed in one go.

To use this feature

  • filter a view to select the records you want to update and then
  • double click on the title of the column to edit,
  • click on the “EDIT FILTERED” button and
  • enter the new value.


Also new – you can now add and remove tags to multiple records. Global editing a tags field will prompt you to add a new tag value to all filtered records. Prefixing your tag with a minus sign will remove the tag from all records instead of adding it.


  1. Only people who have ‘manage’ privileges on a table will be able to bulk edit
  2. Only fields from a view’s parent table (the table the view was created from) can be bulk edited.
    In other words, to edit a field from a table, you have to use a view from that table. If you have two tables, people and organisations, you can’t bulk edit organisation name from a ‘people’ view, but you can from an ‘organisations’ view.


We’re pleased to announce a new charting feature. ‘Year on year’ lets you take a standard date-based chart, e.g. sales opportunity numbers per month, over a number of years, and convert it into a ‘year-on-year’ chart, where only 12 months are displayed but each year’s values are shown as separate series.


In this way, the differences between each year can easily be seen.

Working on this project was also an interesting departure for us in that rather than developing internally, we used an overseas contractor, found on the site – Jin Ming.

This seemed to work out pretty well and may well be something we do again if there are any short-term capacity needs for particular projects.

To set this up for a chart in your system, simply choose ‘year on year’ for the  date filter type, when setting up the chart: