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.

Backups

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.

image00

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.

Notes

  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.

yearonyear

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 www.upwork.com 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:

chart_settings

7658037For developers who use the agileBase API to create and update data within agileBase from a third party product, there’s now a way to further automate the process.

agileBase will now generate a swagger.io compatible API description of any table you want to post to – that means if you deal with accounts for many agileBase customers, you can with a common query get the API details needed to interact with them.

Just make a POST request to

/agileBase/Public.ab with parameters

  • c = the company identifier (the table options screen will show this)
  • t = the table identifier (similarly shown by the options screen)
  • describe_table = true

and the ‘Authorization’ header set to the API key (if the table requires one).

This also makes testing with Postman easier, since Postman can import a Swagger API description – so you don’t have to write a single line of code to test out an API.

postman

Screen Shot 2016-06-28 at 15.27.12

Here’s a neat feature we think people may like – the ability to embed charts into data entry forms. You could for example show sales trends for a product, most popular products for a customer, burndown charts for a project, stock level history for an item etc. – anything someone may want to see when editing a record, without having to go into a separate charts or dashboard section.

Setting this up is particularly easy. Just add a referenced field into the table, then add  a chart into the view that the field references. Instead of displaying the data from the referenced view, the system will then show the chart(s) you’ve added.

 

Continuing one of our main focuses this year of making the system easier to use for partners, developers and other people administrating large agileBase systems, we’ve made taken a few steps out of the new user onboarding process.

When an admin sets up a new user, part of the process is to give them a set of tiles that they’ll see when they log on (unless you want them to start with a blank screen so they can choose their own, but that may be a bit less friendly).

For an admin, this can mean individually selecting and setting options for each tile in turn, somewhat laborious.

We’ve now thought of a way of automating the process – when a user is assigned to one or more roles, which is usually done when setting them up, a set of tiles will be automatically added for them, based on which tiles other users in that role already have.

So if for example most people with the ‘technical’ role have access to a ‘forms and procedures documents’ tile, then any new user added to that role will also get it. Of course they can remove it if they don’t want it, or you can do so for them.

role_membership

This will take place for any user being added to a role, not just a new user, so it works for people moving roles as well as new staff.

Note – this only works if you use roles to grant privileges to users, which is generally recommended, rather than granting each user their privileges individually.

When integrating agileBase with third party systems, the API is really useful. Programmers can use it to send data to websites, to other software such as PowerBI, a  Business Intelligence tool, or to external systems such as label/barcode printers for example. The opportunities are endless.

We now have a way to ‘push’ data from agileBase, rather than ‘pulling’ it from a third party system.

What’s the difference? Simply put, if pulling, a third party system has to regularly ask agileBase whether there’s any new data. It may do this once an hour, once every few minutes or however often it needs. That means extra work for both systems – new data may be reasonably infrequent but when it is there you want it to be transferred quickly, which means polling often even when there’s nothing to send.

Conversely, with ‘push’, agileBase sends a message to the third party system only when there’s relevant data to send.

Not only is this more efficient, it’s less costly too. Each agileBase API call costs a small amount, as set by the capacity that’s been purchased. Third party systems may also have capacity limits or costs which build up over a number of calls. In the ‘pull’ scenario, each call would use server resources and generate costs even when there’s no data to send.

When using push, calls are made only when necessary. Further, you can specify in the settings the maximum number of calls to make per day, so you can control the maximum possible cost. You can set it to anything from once every 5 minutes to once a day – different integrations may require more or less timely data. For example invoice totals may be ok to push to an accounting system once a day but individual customer orders may be best sent as soon as they’re received.

pushmepullyou

a pushmepullyou

Setting up the push API

  1. Firstly, set up a view to operate as a standard ‘pull’ API
  2. Enter a URL into the ‘Push URL (optional)’ area below the other details on that screen. This is the URL that agileBase will POST to when there’s new data.
  3. In the table that the API view was created from, add a new date/time field, accurate to the second, for the system to record when the API push was last used
  4. Go to the ‘workflow’ section under the view’s ‘manage’ tab.
    1. for ‘workflow action’, select ‘send data to a third party system using the API’
    2. for ‘recording the time of the last action’, choose the date/time field created above
    3. choose a minimum interval to wait between pushes

The system will now make a POST to the URL specified in step 2 whenever there’s new data to send. It will contain one parameter, ‘json’, which is a JSON representation of all the data in the view.

Selecting data to push

How do we know which data is new and wants to be sent out via the API?

That’s up to you – any filters can be added to the view to select data you want. Commonly, you’d use the date/time field set up in step 3. When a push successfully completes, every record in the view has this field set to the current time.

Note: if the push encounters an error for any reason, say the third party system returns a HTTP error code rather than the expected ‘200’ code for success, the timestamp won’t be set.

A few common scenarios would be:

Pushing any data modified since it was last pushed

To do this, add a boolean calculation to your view, something like

needs pushing = {last modified [auto]} > {last pushed}

where ‘last pushed’ is the name of the timestamp field you added in step 3 above.

Then add a filter on the view ‘needs pushing equals true’

Pushing any new rows that have never been pushed before

For this scenario, simply add a filter to the view ‘last pushed is empty’

Pushing only rows not yet marked as received

In some cases, you may want to be even more prudent than using the internal timestamp. The third party system could make a separate API call to agileBase for every row that’s received, telling it to update the row with an ID to prove receipt. That’s more API calls of course, but some situations may warrant it.

 

Follow

Get every new post delivered to your Inbox.

Join 194 other followers