With the release of a new product built with the agileBase platform coming soon (we’re all very busy here!), we’ve been polishing the system and doing some work to make sure that first time users can get all the help they need if and when they need it.

There’s some new introductory help (see the video at the bottom of this page) but as well as the built-in help for various standard actions like filtering, we’ve been improving and adding features to let administrators set up their own help content for various areas of their system. As these features are now built into the platform, you can take advantage of them. They can be particularly useful if for example you take on temporary or seasonal staff, or are growing quickly.

Adding help content

Content can be added to a number of areas:

Individual fields

Sometimes a form field needs a bit of explanation in addition to it’s name (which should be short and descriptive), e.g. if there are rules to follow when filling it in.

To add field help, type into the ‘description’ area when editing a field in the admin interface. If the description’s shorter than 25 characters, it’ll display as a tooltip when you hover over the field. If it’s longer, a question mark icon will appear next to the field. Clicking it will display your help text.



It’s also possible to link to external web pages, images or videos instead of writing text. Just enter a URL into the description and the user will be directed to your help resource when clicking the question mark icon


Help can be added to a whole group of fields by adding a description to a ‘separator’ field in the administrator interface.

An empty view

The first time a new part of a system is used, there may be no data in it. You can now create text to be displayed in this ‘blank state‘. In the manage tab of a table, enter some text into the ‘purpose’ area. This will be shown to the user if there’s no data when they open a tile and look at a view.


Help videos

Finally, to help with the more generic aspects of using the agileBase platform, such as moving around the system, we’ve started making some new videos. Here’s the first, a very quick introduction to navigating and finding data.




Here’s an addendum to last week’s update about letting users manually trigger workflows (chains of actions that run behind the scenes). You can now set them up to trigger not just for particular views, but for individual records.

What that means is a user can run simple or complex custom tasks with the click of a button. Generating a document, sending an email, making a number of record edits with one click, cloning a record in a ‘custom’ fashion – all are now possible and more.

Taken together, the agileBase platform now has a really powerful workflow engine, which can

  • run tasks for records in bulk or individually
  • be kicked off by the user or automatically behind the scenes
  • chain tasks together to carry out many actions at once

Setting this up

  1. As an administrator, create a workflow view.
  2. In a table, add a referenced field, referencing that view

The referenced field will appear as a button in the form when editing a record, with the name of the view. Pressing the button will run the workflow specified, but only for the record being edited, not all records in the view.

(To accomplish this, a filter is added to the view to filter on the row ID of the selected record).


One other more minor change has also been released this week – an update to the ‘history’ function which people can use to look at past edits to the current record. It now shows not only direct edits to the record, but also edits in any tabs (if the tab contains one record only):



You may know of workflows, or automations in agileBase. These are automatic tasks that run in the background, to do things like send emails from the system, generate PDF documents or create/update records.

Due for release tomorrow is a new feature that leverages the workflow engine to massively increase the power of the user interface.

In short, you can now create workflow actions that can be run ‘manually’, from buttons in the user interface, rather than automatically in the background. Furthermore, you can chain actions together, to make multi-step workflows that run at the click of a button.

An example is the ‘print labels’ button here.


Each step in the workflow can do one of these tasks:

  • create new records with specified values
  • edit values in existing records
  • remove records (if there are no dependencies)
  • lock records to prevent further editing
  • generate PDF files from data in the system, based on a template
  • send emails, merging in data from the system
  • send data to a third party calendar, e.g. Google calendar or Office 365
  • push data to a custom third party system using the API

So for example, if your system receives customer orders that need to be produced on the factory floor, you can create an automation that takes a snapshot of all the orders so far and generates production sheets for the quantities required. It can then be run multiple times a day on demand to pick up new orders.

Developers commonly wish to have ways of manually interacting with third party applications, e.g. to send data to a custom app for processing, this should be very useful for them too.

Setting up

To set up a button, first create a workflow as normal, using the ‘workflow’ button in a view’s ‘manage’ tab.

For the frequency, rather than say ‘run workflows every 10 minutes’, select ‘manually’.

Note: to chain workflows together, select a workflow name under ‘chain workflow’. That workflow will run as soon as the first completes. You can chain as many as you like together. Remember to set frequency to ‘manual’ for all of them.

Finally, create a button. This is simply a matter of selecting a view where you want the button to appear. When the user clicks that view in a tile, the button will appear above.

In the manage tab for that view, under ‘chain workflow’, choose the workflow view that should be run (the start of the chain if there’s more than one in the chain)


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.