Learner progression and diagnostics in agileBase


We’ve talked before about ‘learner progression’ for developers using agileBase. The idea is to help people increase their developer abilities at their own pace, up to the level they want to get to, whilst still allowing control and oversight over the direction of development by the organisation.

For example, once someone has been using agileBase for a while, they may like to start making small changes to particular views, e.g. adding in fields they need to see for their work or creating new charts. These changes will only be visible to them.

Once comfortable with making changes, some people may want to progress to develop functionality in a more substantial way, to make changes visible across the whole organisation.

There are a number of learner levels we have in mind, which we’ll discuss with customers and in public in future posts.

To make this fully a reality, there are a number of strands we’ve been working on and we’re excited to show the fruits of some of those developments today.

The three primary strands are

  1. for new users, making it easy to ‘dip a toe in the water’ of development, starting them on a potential path to further progression
  2. for developers, general usability improvements to make that path a smooth one
  3. for advanced developers (architects), adding features to allow easy diagnostics and deconstruction abilities – we’ll explain this below

We are tackling this work from both directions – focussing on both 1 and 3 and working inwards to 2 from either end.

On number 1, some great design work has been done, which will see the light of day in a future release.

Today’s new features are actually from the more advanced end of the spectrum and are about diagnostics.

What does that mean? 


After any application has had a significant amount of development, the app builders will often need to go back and ‘refactor’ it – change how it works, make it more efficient, remove unused features etc. as well as adding further functionality. This applies to any software development but arguably even more so to apps built on a ‘low code / no code’ platform like agileBase, as barriers to entry are so low and it’s easy to prototype things.

Often when there’s a need to be able to look into an application and see how it works – it may be quite a while since the initial development was done, different people may now be involved, or it’s just very big and you need to remind yourself how everything fits together!

So that’s the background, let’s get on to how we’re addressing these issues.

Today’s updates

Firstly, the history/search for developers has been massively beefed up.

Previously, you could just see recently edited views and tables. This was really useful for flipping back and forth when making a few changes to related views, but finding and managing lots of views was still not as easy as it could be. You had to know the name of a view to search for it for example.

Now, there are some added tools to make larger scale projects a lot more consumable. We’ll go through each new option in turn, there are quite a few.

The view/table filter

Here’s a screenshot of the history menu, which appears when you click the history icon in the toolbar at the top (the clock icon) if you’re in build mode, i.e. editing a table or view.

The top parts are exactly the same as before – showing the search box and a graph of recently edited tables and views.

Below that is a new selector, so you can filter down the list of items when looking for something. The options are

  • tables – show tables only, exclude views
  • views – show all views
  • workflows – show only workflow views. When this is selected, a second row of options appears, to let you select the type of workflows you’d like to see. In the screenshot above, you can see that email notifications are selected
  • apis – show tables and views which have APIs enabled i.e. which allow third party software to send data into agileBase via a table, or extract data via a view
  • more – additional options appear allowing you to select views which are used for other purposes, e.g. to control field visibility or locking, referenced fields or tabs

Any search you enter will be filtered by this selection, or you can leave the search blank to see all.

So it should now be easier to find what you’re looking for if you know what a view does, even if you can’t quite remember what you called it.


To the right of the filter selection, there’s a dropdown which lets you choose which order to show results in. The options are

  • recent first – the default, show recently edited views and tables at the top, followed by all others
  • group by tile – shows a heading for each tile, with views underneath. This is another good way of finding something if you don’t know the exact name
  • least used first – this is not an obvious one, but can be really useful when trying to work out which areas may be candidates for removal

The ‘least used first’ option requires some further explanation. When you select it, you’ll see a count of how many times each view has been accessed per day, on average.

A view count includes not just direct accesses, but also accesses of any views which depend on it. So for example, you may have a chain of joined views

monthly sales report -> daily sales by category -> all daily sales

Whenever someone opens the ‘monthly sales report’ view, that will increment the count for all three of those views. This then gives you a way of seeing which views are important to the system, even if they’re not directly opened by everyday users.


Any view or table in the history list can be pinned to the top of the list. Just hover over it and press the pin button.

That can be useful when you’re planning to make a large change to a part of the system, involving a number of different views and tables. You can line them all up, ready to work on.

Field uses

The second of today’s major updates is related but is in another area of the system. When editing a table, clicking on a field will show the properties. In those properties, you can see the views that field is used in. You can now filter that list in a similar way to the filtering above, i.e. to show only workflow views, only API views etc.

Note only the uses the field actually has are shown as options to be ticked.

Other updates

Other recent changes to make life easier for advanced developers/architects are

  • When editing a table, you can now see any workflows which act on that table. I.e. any workflows which create or update records in the table, generate documents for a file field in it etc. These are displayed at the top right, in the table properties sidebar.
  • When editing a calculation, you can search for fields to include in the calculation and drag them into the editing space. Hovering over an available field will show what type of field it is and any relevant properties. In particular, for dropdown or tags fields, it will show a list of the available options, which you may want to use in the calculation

We hope you find all of these updates useful and stay tuned, more work in this area will become available soon.