Agilebase – recent improvements

It’s come to my attention that we’ve not published an update about Agilebase features recently, since the last in April.

That’s largely because we’ve been focussing on preparing for the Bath Digital Festival – please do come and see us on the 12th July.

However development has continued apace. Here are some of the recent updates that are shortly to be released.

Many multi-tenanting improvements

New option ‘allow only multi-tenanting views to be seen’.

Multi-tenanting is a really powerful feature – it lets you create a single app, which can be used by multiple groups of people, each of which see the same functionality but don’t share data, i.e. they only see their own data.

A recent example is the Bus Services Registrations System for the West of England Combined Authority. Each bus operator can log in to create and update the details of services they run – of course they only see & edit their own services, not those of other operators.

We’ve now added a feature to allow ‘mixed multi-tenanting’. That’s where you may want only certain parts an application to be multi-tenanted. You can set it up so either

a user can only see certain parts of an app, those which are multi-tenanted for them, in which they only see their own data
the user can see other parts of the app, which contain shared data visible to all

These capabilities can also be mixed and matched within an app.

For example, if you have an internal CRM system for your company, you may wish to give customers the ability to log in to see their support tickets. They shouldn’t be able to access other parts of the system, such as contact details or sales enquiries.

However in other cases, you may want people to be able to see shared resources, like public data feeds or support & documentation.

This can now be controlled with a new option for roles, ‘allow only multi-tenanting views to be seen‘.

When that is un-ticked, users will be able to see all views they have privileges on. For any that don’t contain a multi-tenanting field, they will be able to see all data.

If it is ticked, the list of views available to the user will be restricted to those which contain multi-tenanting fields applicable to the multi-tenanting roles they’re in, even if their privileges would otherwise allow them to see them.

That allows you to easily add third parties (e.g. customers or suppliers) into your system without needing to worry about them seeing anything they shouldn’t. For example, you may want them to see support tickets their organisation has raised, but not an internal report of support ticket response times for each customer.

Individual multi-tenanting

Multi-tenanting is usually handled via roles, which allows easy control over potentially large groups of users. However in some simple cases, you want individuals, not groups, to see their own data. For example, an employee applying for holiday time might only be able to see their own holiday allowances, not those of others.

In that case, you can set up restricted access when editing an individual user.

‘Missing multi-tenanting’ warning

The confidentiality of data is obviously a key concern when configuring multi-tenanting.

A prominent on-screen warning now appears if you add a new user, or edit an existing one, who doesn’t have any multi-tenanting roles, if multi-tenanting roles have been set up for the organisation. That helps prevent someone forgetting to add a relevant role to a new user, which could result in them having access to data they shouldn’t be able to see.

Reliable performance for complex views

Apart from multi-tenanting, a number of other general improvements have been made. The first is the ability to ‘lock’ the query plan.

To explain, when a view is slow and complex, perhaps querying a lot of data, Agilebase sometimes tries different ‘query plan’ options. These are different ways in which the underlying database, PostgreSQL, can find the results. Nine times out of 10, PostgreSQL is intelligent enough to pick the best one automatically, but sometimes an alternative is faster.

Every now and again in that case, Agilebase will explore different plans. However if you know from experience which one works best, you can manually ‘pin’ the best one, to avoid slowdowns – it’s not uncommon for the best plan to be very quick but the slowest to time out after 60 seconds.

You can see the documentation for more info.

Visibility rules bugfix

A small bug with field visibility rules has been fixed, so if you’ve experienced strange behaviour in this area, please try again and let us know if there is any continuing issue.

Emailing record history

It’s now possible to include a log of recent changes to a record, in notification emails about that record. For example, if you have community users external to the organisation editing data, you may want notifications of any important changes. Please see the docs for how to do that.

We do hope these updates are useful. As always, please do let us know any ideas you have for other useful functionality you’d like to see.