Sometimes agileBase changes are made by developers, using agileBase as part of a larger infrastructure, e.g. interfacing with a website or third party applications, like accounting systems for example.

We’ve now introduced some features that will make that work easier to carry out.

Setting internal field IDs

Usually when a new field is created in agileBase, it gets assigned a unique internal ID. Usually this is never seen by anyone and is only used by the platform itself, but in cases where the API is used, like the integration examples above, it comes to the surface.

The automatically generated ID is just the user-facing field name followed by a random string of characters. However it’s now possible for administrators to specify their own internal ID when a field is created.

To do this, when typing in the field name, simply use a | sign (vertical bar) followed by the internal ID you want.


This becomes very useful when using multiple servers, e.g. developing first on a ‘test’ server, then copying the same work to a live server. In this case, you want IDs to remain the same, otherwise third party systems will need to be updated accordingly with potentially lots of field name changes.

This system will also be used for table and view names in future.

API error details

Another improvement to workflows using an API: if an API is called and there’s a problem resulting in an error code, the system will now output a message as a custom header, in addition to the error code and details in the body. This allows concise and potentially machine-readable error messages.

The header name to look for is X-AB-error.

Note this change is not yet live at time of writing but will be released with the next version, scheduled for next week.

There are a couple of places in agileBase where an a system administrator can describe in a broad outline the purpose of a table or view.


Recently we’ve seen people working on projects with an increasing number of collaborators and have seen the need to expand this system to apply in other places in the administration interface.

You can now add comments against calculations, which are perhaps the most complex area of a system. Notes or comments can help other people understand what the calculation’s doing, what it’s purpose is, where it’s used etc. – they usual who/what/why/where questions. They’re even useful for the person who wrote the calculation, if they come back to it some months later for editing!




From a developer’s point of view, the agileBase platform can be thought of as, at it’s heart, a tool for building database applications. The starting point is building and connecting tables and views, then of course the platform supplies lots of additions: the great user interface, powerful business logic, workflows, security rules etc.


creating some connections

We’ve always tried to help the administrator by providing the user interface and features to remove a lot of the hard work of all of those stages. For example, whenever a major change to a view is made, the system automatically re-creates any dependent views too.

Recently, we’ve had some conversations and meetings with developers and administrators, to see how the administration interface can be further developed to fit in with best development practices, particularly when working on more complex projects. Thanks to all involved for their time, effort and enthusiasm!

There’ll be lots coming out of this continuing work, but the first fruits can already be seen with a release that beefs up one of the core tasks when creating database views – working with joins. When building complex systems, views are often broken down into many ‘sub-views’ for convenience, then joined together to form the output the user sees.

Working with these joins is now easier – rather than hunt for each joined view when working on different components, you can simply click a view link to move to it’s own management screen.

Because a picture’s worth a thousand words, the joins screen also shows a graphical representation of the connections in a view – both the joins in that view and any other views that join to it. So you can quickly see which views have lots of dependencies. Here are a couple more examples:




This progresses the ‘graph’ visualisation work started last month.

There’s a lot more in the pipeline too, which we look forward to talking about soon.


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