An agileBase example: de-duplicating company records

This week we have been asked by a customer to do a bit of work that’s interesting enough to write a blog post about – always nice!

Preventing or removing duplicates is a common requirement in CRM systems and other database apps. With a multi-user system, it’s not uncommon for two different people to try to add the same company details twice for example, without checking whether they’re already in the database.

On the prevention side, there are a couple of features of agileBase which help. The first and most obvious is the unique option for fields. With this enabled on a company name field for example, people will be prevented from entering the exact same name twice. If appropriate this can be slightly improved by also turning on the text case option to force all entries to the same case as they’re entered.

However, even this isn’t going to catch all duplicates. Company names can often be entered slightly differently, e.g. with ‘Ltd’ or ‘Limited’ following the name, the word ‘The’ at the start or with different punctuation.

To catch these, the build in duplicate detection can be used, activated for all record title fields. When someone enters a name, the system automatically searches all existing records for any similar names.

Reporting existing duplicates

Even with all these features we will often still want to find duplicates that in one way or another have made their way into the system. Maybe the data hasn’t been manually entered by staff, but imported, e.g. from spreadsheets, or via an API from other software or a website. However, in our case, the cause was the merger of two different business units and their data.

Finding ‘close match’ duplicates is an interesting problem that can be solved in a number of ways. Here’s a short introduction and there are many articles and papers which go into the mathematical details of various methods.

We chose to use trigram matching, an approach which is supported natively by the database agileBase uses, PostgreSQL and which is fast and effective. As they say, “this simple idea turns out to be very effective for measuring the similarity of words in many natural languages”.

A trigram is a set of three consecutive characters, for example ‘agileBase’ would contain ‘agi’, ‘gil, ‘ile’, ‘eBa’, ‘Bas’ and ‘ase’. There are some further considerations, for example how to treat the starts and ends of words, which are explained well in the PostgreSQL documentation page.

In brief, we simply count the number of trigrams two words or phrases share as a proportion of the total number.

Our goal

So as a concept, what we want to do is compare every company name in our database with every other company name, get a similarity score from the pair and sort the results in order of descending similarity, with a cutoff to stop showing results once they fall below a certain similarity threshold.

An immediate thought is ‘how many comparisons is that’? Well, the database we’re looking at currently has 13,000 companies in it. That would mean 13,000 ^ 2 = 169 million comparisons. Ideally, we’d like the system to continue working well as the number of records significantly grows. At 100,000 records, the number of comparisons would be ten billion.

As this ‘naive’ number of comparisons is the square of the number of records, we’d like to get that down as much as possible in order for performance not to suffer.

We can immediately cut the number in half – if we’re comparing Company A to Company B, we don’t then also need to compare Company B to Company A.

We can also use the fact that duplicate names are very likely to start with the same letter. There are some exceptions, for example Bristol University and University of Bristol (only the latter is correct!) however that will be uncommon and the tradeoff is likely to be worth it. To take advantage of this fact we will also need to strip any common prefixes from the names to compare, for example ‘The’ as in ‘The University of Bristol’.

Assuming an even distribution of first letters, the number of comparisons would be 

(((n/26)^2) x 26) / 2.

(also taking into account cutting the number of comparisons in half as above).

For 13,000 names, that would result in 3.25 million comparisons, down from 169 million. For 100,000 it would be 192 million, down from 10 billion. Still quite a lot, but we can give that a go and see how it works out.

Actually, thinking about it, if we import more sets of data from other sources in future, we will only need to compare the newly imported companies with all others, not do a full comparison of everything with everything. So I don’t think we’ll ever get anywhere near the top end of those numbers.

There are other reduction methods you’ll be able to think of – for example, comparing only those where postcodes are the same (assuming each company has only one address, or HQ details are all filled in). However the above is what we went with.

Implementation

Ok. Let’s move on to making this work.

Our first step is to create two views, which we can then compare with each other. Each view will have the ‘cleaned’ version of a company name and the first letter of that name. Let’s add two calculations

simple name = 
regexp_replace(
    lower({a) companies.company name}),
    ‘^the\\s’,
    ”
)

first letter =
substring(
    {simple name}
    from
      1 for 1
)

These calculations use SQL to 

  1. convert the name to lowercase and strip any leading ‘the’
  2. extract the first letter of the resulting ‘simple name’

Once we have these two views, which we’ll call ‘similarity check 1’ and similarity check 2’  we can join them together and do the similarity calculation.

From similarity check 2, we add a complex join on the ‘first letter’ calculation to the first letter calculation from similarity check 1.

Then also in similarity check 2, we can add a boolean (true or false) calculation to allow us to cut the number of comparisons in half:

first comparison = {similarity check1.id:companies} < {companies.id:companies}

(here, the name of the table containing the company names is, well, ‘companies’). This calculation outputs true if the company on the left hand side has a lower internal ID than the one on the right, or false if not.

We now just add a filter on that calculation:

first comparison = true

Now to the similarity check itself, which is simply

similarity =
similarity(
    {similarity check 1.simple name},
    {similarity check 2.simple name 2}
)

All of this has been in the ‘similarity check 2’ view. We now have all the information we want to look at in one place. Well, almost – for people to actually use the system, they’ll probably want to look at the actual company names, not our simplified versions. They may also want to see other information, like perhaps the account manager for each company.

So we’ll create a third view, just called ‘company duplicates’, which pulls in the calculation from ‘similarity check 2’ but displays things in a more user friendly manner.

‘company duplicates’ joins to similarity check 2 on the internal company ID. We then sort and filter on similarity, using a filter ‘similarity > 0.7’ in our system.

I’ll leave the details of adding additional fields such as account manager etc. It is worth noting that to speed things up for users, we set ‘similarity check 2’ to cache its results. On our dataset it takes a few seconds to load – with the results cached, users can view and search the data with better responsiveness. The load on the system is also reduced.

Here’s what the results look like (details have been changed or pixellated, but you can see the first couple of example names compared.

Hopefully this can act as a useful pattern for people to follow if they want to do similar de-duplication work.

The next step could be to tackle the process of actually merging and deleting records once duplicates have been identified. For example, workflows could allow details of two company records to be automatically merged together. However that is a task for another day!

Calendar and other updates

It’s been slightly longer than normal since our last release of the agileBase platform, but to balance that there’s tons of stuff packed into this one.

We’ve been working closely with partners to make this a significant update with lots of usability improvements. There aren’t that many new features and users shouldn’t be impacted by any of the changes, but many should find the system easier to use and more capable.

Improvements for users

Calendar updates

First up is the built in calendar. 

  1. Drag and drop is now supported for events, so it’s much easier to reschedule things. If an event is dragged from one day to another, the time of day remains the same. Similarly, if an event is moved from one month to another, the day of the month remains the same. Events can of course be edited by clicking on them to fine-tune any details.
  2. Event editing popup: clicking an event will pop up a small window to edit the main details of an event. You can then click through to the full record if you like, but making simple changes to e.g. an event title or time is a lot quicker.
  3. Weekends are now always shown, but smaller. Previously you could toggle them on and off by clicking the ‘month’ selector at the top of the screen, but this wasn’t particularly obvious to new users. Events can now easily be scheduled on weekends if necessary, but the space assigned is half the normal day width to allow more content to be visible in week days.
  4. A new year planner view is now available. This shows an entire year on one screen in a ‘timeline’ format, letting you schedule projects, milestones or other events easily. It works really well with the new drag and drop capability too.
  5. Calendar drill-down: individual day numbers and week numbers are now clickable, navigating you to a day or week view as appropriate, for the period selected.

Simple form layouts

There’s a new layout option for simple forms, which hides the first tab if it has no contents. This is easier to show with an example. Here’s what a simple form may have looked like before. It has just a handful of fields, no blocks and a tab.

Here’s what it looks like following the update. The unnecessary first tab is removed and the remaining tab is selected by default (if there is more than one tab, the first one will be selected by default).

To hide the tab, just ensure that there is only one separator field in the table and that it’s the last field (or at least that there are no visible fields after it).

Customising chart subscription times

Users can select to receive certain charts by email – https://docs.agilebase.co.uk/docs/charting/#subscribing-users-or-roles-to-charts

It’s now possible for people to select what time of day they’d like their charts to arrive, which may be useful for e.g. shift workers who need to see particular sets of data when they start work.

A user can edit their profile from the homepage to do this, or an administrator can set the time for them by editing their user details

Improvements for administrators

Simpler multi-stage workflow setup

Often, workflows are made up of a ‘chain’ of individual actions, For example, if a new enquiry comes in from a website form (via an API), you may want to 

  1. create a new organisation
  2. add a contact to that organisation
  3. add a sales lead, related to that contact and organisation

Previously, to link these three records together, you would have to add hidden fields to record the fact they all came from the same web enquiry along with lookup calculations to link them to each other.

Now, you can just tick ‘auto-set relations’ in the workflow settings of steps b and c. When a workflow creates a new record, it remembers which one it was. Later workflow steps in a chain will automatically link to it, where a relation exists.

Renaming fields

Previously, if a field was used in an email notification, chaser or ‘create record’ workflow, renaming that field could break parts of those things, requiring you to manually find and fix each.

Now, the system will automatically update references to the field in the background, whenever a field is renamed.

Assigning users

Currently, using the ‘list of users’ option (https://docs.agilebase.co.uk/docs/fields/field-options/text-field-options/#lists-of-users) you can assign a user to a record e.g. as an account manager or responsible person. 

Now, you can narrow down the list of users to only those with a particular role e.g. managers. This can work with multiple roles too – please see the documentation link for more details.

Two Factor Authentication (2FA)

Some users have been finding text-message based 2FA problematic, in that text messages take a while to arrive, or never arrive at all. This can be for many reasons, for example lack of reception, problems with the phone network or the fact that a valid mobile phone number hasn’t been entered (e.g. if a landline is entered, that won’t work).

For those reasons, 2FA by text message has been deprecated. It will continue to work for users who already have it set up, but new people, or those who don’t have a phone number entered, will only be able to use app-based 2FA, which is far more reliable.

We will continue to monitor 2FA usage and in the longer run are keeping a close eye on the progress of upcoming technologies such as webauthn, which allow biometric or hardware key authentication mechanisms.

User interface updates from partners

It’s always good to have new eyes on the platform, and this month we’ve been working on projects with a couple of new partners – or at least supporting them while they do most of the work! 

During this period they have noticed a couple of improvement opportunities in the user interface, so this release is a minor one to implement those. Thanks to Argenta and Techni-K for their input.

Read-only mode

Certain people e.g. contractors or external parties may only need read-only access to some data in the system. The read-only version of the record screen has now been improved to remove some glitches, such as duplication of the field names of checkboxes and make everything look better.

Embedded data fields

An option has also been added for referenced data fields to allow you more control over how they’re displayed on screen. 

Below is how each of the four options will look like on screen to a user.

Panel fieldname and content fieldnames:
Panel fieldname, no content fieldnames
Content fieldnames
no fieldnames

To use this new functionality, go to the fields tab for the table the field is in and click ‘edit options’. Then choose a value for the ‘display of fields’ option.

Optional colouring for date fields

The system automatically highlights out of the ordinary values with colour, based on how many standard deviations from the mean they are. This works with both numbers and date fields.

For numeric fields, you have always been able to enable/disable this behaviour in the field options. That has now been extended to date fields too. Previously it was always enabled, now it can be disabled if necessary.

More intuitive navigation of sub-records

Navigation arrows have been added to the headings of sub-records (records in a tab of the main record – ‘black pepper’ in the below example), to make looking through many records quicker and more obvious.

We hope these small tweaks make a difference. We look forward to hearing more of your feedback in future.

Detailed API logging

For those customers who make heavy use of the API, we’ve just released some updates to the enhanced audit trail feature which will make keeping track of API usage a lot easier. 

These can help with things like

  • Seeing trends in the volume of usage over time
  • Identifying any performance bottlenecks
  • Checking that any caching layer you have is operating correctly

In short, to keep things running smoothly, troubleshoot easily and control costs when there are complex sets of interacting software systems, many API requests per second and/or large volumes of data being transferred.

First, here’s a quick recap on the existing benefits of enabling Enhanced Audit Logging (£15/month).

  • Extended retention periods (upgradable to any length of time required)
  • The ability to create views and charts from the log data, so you can report on it in the same way as any other data in agileBase

For API calls, the data logged includes

  • Date and time of the request
  • IP address of the external client making the request
  • The API view the request was made against
  • Any data filters and row limit applied to the request

What’s new?

Additionally, the following new data fields will now be logged:

  • Count – if a number of similar requests are made in quick succession to the same API view, they will be merged into one log line. The count field will then show the number of requests this line refers to
  • Processing time – the total time in ms (thousandths of a second) taken to serve the request. If count is greater than one, this will be the total time for all the requests the log line pertains to
  • Of which Q time – to achieve a fair level of load balancing, agileBase operates a separate API request queue for each customer. If a request arrives and the system is still busy processing a previous request, the new one gets held in a queue. This field shows how much of the total processing time (ms) was spent waiting for previous requests to complete
  • Rows – the total number of database rows returned by the request(s)
  • Bytes – the total size of the response(s) for each request i.e. the amount of data returned

These can all be used in charts and reporting. Please note if you want to find average processing time, queuing time, rows or bytes per request for a log line, you need to divide by count.

Hopefully this data will prove useful to customers, particularly those interacting with many third party systems or sending large volumes of data to external systems via the API, perhaps for transaction processing.

Please let us know if you’d like to see any further metrics.

Global editing privileges

It’s a little bit surprising to see but at halfway through the year, development of the agileBase platform is going roughly according to plan, as set out in the 2020 roadmap last December.

We’ve been concentrating on building in capabilities to let businesses “scale up without screwing up” – in practical terms, things like administrator controls, efficiency, data privacy and security. Some of these things have been going on behind the scenes but many we can showcase and introduce as platform features.

One of those we can introduce today – granular global editing privileges.

Global editing is a powerful feature that allows users to quickly update many records at once – it works a bit like “find and replace” in a text editor.

This is obviously a feature that benefits from restricting the number of people who can use it. If you’re a food manufacturer for example, you may want to be able to bulk replace one ingredient with another in all recipes, but you may not want everyone to be able to use this capability!

Until now, global edit rights could be assigned by giving someone MANAGE privileges on a table. This privilege level comes with many additional capabilities though – anyone with those privileges can manage the structure of the table, adding and removing fields.

Global editing rights can now be assigned on their own. There is a new checkbox in the role properties page, ‘allow global editing’. Adding a user to this role will allow them to perform global edits on any table they have EDIT privileges on.

This should be useful to many people, particularly those using multi-tenanted products built with agileBase, who can’t be assigned manage privileges. 

People with manage privileges on table can still globally edit the data, whether or not they’re in a role with ‘allow global edit’ ticked.

June 2020 agileBase updates

This month’s updates cover a range of areas, including documentation, API improvements and user interface improvements. 

In the background we’re also working on some major developments to help administrators. All of these improvements aligning with our vision of supporting ambitious organisations across all the phases of their growth. A sneak peek of some of that work is at the end of the page.

New Documentation

With the help of our partners at Little House Consulting, the agileBase documentation has had a comprehensive overhaul. We’ve updated the technology behind it (we now use the Hugo framework with Algolia search), structured and greatly expanded the content to cover every aspect of setting up and developing with ‘no-code’ in agileBase.

There’s still work to do – the introductory sections are in progress and links to relevant documentation pages are being added to the administration user interface for example, but it’s now in a state where it should be useful, so please take a look by going to

https://docs.agilebase.co.uk and clicking the ‘Docs’ link in the top navigation.

Please let us know any early feedback or areas to improve on.

Product Help

As an application builder, you can also add your own custom help for users at many levels throughout an application – field, block of fields, table, tile and view for example.

That help is being displayed in more places. For example, help is displayed as a tooltip when hovering over a form tab. Tooltips also appear for tiles when on the homepage. More updates are planned, so watch this space.

Receiving files via the API

Interactions amongst the many software applications and platforms a business may have, is increasingly important in today’s world. No app is an island!

One of agileBase’s main strengths is it’s comprehensive API which can be used to transfer data in and out of agileBase. Third party integration tools like www.zapier.com help make the process really easy to set up.

Now, as well as accepting data from third parties, agileBase can accept document files. (For example, contract documents generated by a third party system can now be sent to agileBase for storage).

Until now, that has required posting data as multi-part/form data (see documentation). 

Now however, an additional option is available – simply supply the URL of a file as the value of a file field parameter when sending data and agileBase will download that file, saving it into the system.

This method is Zapier-compatible, 

Thanks to Britannia Windows for requesting this.

Please let us know if you’d like a hand trying this out and we can walk you through the setup.

Inline uploading of documents in a tab

Until now when there was a document field included in an inline editing view under a tab, you could only download documents. Now you can upload them there too. An example could be attaching evidence to a milestone in a project.

Thanks to Foodcase for suggesting this.

Personal Charts

The ability to create charts of data is a popular feature, allowing users to interrogate data and share reports.

Until now, only people with manage privileges (a “manager”) have been able to create charts, but everyone who has permission to view the underlying data has been able to see those charts.

We’re now changing it so that any user can create a chart, but it will be only visible to them. However a manager will be able to view all charts, whoever created them, and can “promote” them so that they are visible to all others. To promote a chart, they need only edit it and remove [username] from the end of the chart title.

Coming up…

If you’d like to be an early beta tester of this functionality, please let me know.

Thanks for reading and we look forward to introducing some more exciting updates in the near future.

agileBase release

Calendar searching

The highlight feature of this May 2020 release of agileBase is calendar/timeline searching. 

Typing into the new search box at the top of the calendar will reduce the entries on screen down to those that match. This has a couple of specific uses –

1 – you can now view data by two different facets. For example, imagine you have a number of calendar views set up for each type of event – one view for board meetings, another for general meetings (zoom calls), one for customer calls, another for pre-arranged demos etc. These will be displayed in different colours on screen.

You may want to see just events which you (or another specific person) are attending – typing a name into the search box will narrow down the results.

2 – when showing a grid (timeline view) with swim lanes for event classes (perhaps a set of milestones with a lane for each task, like a GANTT view). In this case the search can be used to reduce results down to which task/milestone you’re interested in.

Thanks goes to Beacon Foods for initially requesting this.

As the first ‘minimal’ release of a new feature, we’re keen for everyone to try it out and give us feedback. Later releases may introduce new capabilities.

Other user interface improvements

Another calendar update is that you can now toggle the display of Saturday and Sunday in the calendar, to allow more space for the rest of the week. To hide weekends, click on the active calendar button at the top of the screen (e.g. ‘year’, ‘month’, ‘week’) and to toggle them back on, just click again.

Searching standard views has also been tweaked – previously, double clicking in a filter box to select the current text was difficult due to scrolling issues. These have now been resolved. Thanks to the West of England Combined Authority for reporting this.

Calculations

Calculations are now no longer converted into lowercase – that means you can enter text in any case into a calculation definition and it will be retained as typed. So there’s no need to sprinkle so many ‘initicap(text)’ and ‘upper(text)’ functions throughout them.

Data security corner – extra login information

Finally, continuing the focus on improving security for users and companies, there’s a tweak to the way login information is logged this month that administrators should be aware of.

In addition to logging the IP address, internet provider and country of each login, the nearest city will also be included. This extra information may be useful to administrators e.g. when investigating any suspicious logins.

Please bear in mind that for many reasons, ‘the accuracy of IP geolocation information can vary wildly across service providers’. Particularly when organisations are increasingly using Virtual Private Networks (VPNs) to improve their employees’ data security, the results may not represent their real locations. However, even then the functionality can be useful to look at how many people are using recommended VPNs and proxy services.

As the format of location data is changing, the system’s new location detection may be triggered the first time someone logs in after this release, resulting in them getting a Two Factor Authentication prompt. People who don’t have 2FA enabled will get an email notifying them of a login from a new location.

May update for API developers

The main feature of this week’s platform update will help a select, but growing and important group of people; developers who build software that interfaces with agileBase via the API and who utilise a test server.

A test server (or virtual private server) is often used in this scenario, to test your API calls against as a way to reduce the chance of any bugs affecting live data. 

For example, if you have an API call which creates new contacts in your CRM system and it gets stuck in a loop, creating thousands of duplicate contacts, you’d want that bug to be found when running on a test system rather than on the live one.

Up until now there was one issue that was slowing adoption of this service down, random object IDs. 

When you use an API, you reference the agileBase object (e.g. a table, field or view) by its internal name. When an object is created, it is assigned an internal ID made up of random characters. The problem is that if you add an object to the test system, run some tests, then add it to the live system, the live one will have a different internal ID. Hence any API calls referencing it need to be updated, introducing possibilities for errors that can’t be checked without actually going live.

But not any more – internal IDs are now completely deterministic. An object created in one instance will have exactly the same ID as one of the same type with the same name in another.

Thanks to One Team Logic for bringing this feature idea to our attention.

If you’re interested in accessing your own test instance, please let us know, we’ll be happy to discuss your requirements.

Data security updates

For a long time we’ve been championing Two Factor Authentication (2FA) as a breakthrough improvement to account security and we regularly like to release updates that encourage adoption and enhance security – most recently requiring 2FA to be enabled before someone can export any data to spreadsheet.

Thanks to all users who’ve jumped onto the 2FA train – some accounts now have over 90% adoption rates.

This release continues that work. Any user who doesn’t yet have 2FA enabled will get a reminder email once a month, informing them of the benefits of doing so.

Please keep the ideas coming, we look forward to hearing from you.

A low-code / no-code introduction

Next week (on Tuesday 14th April at 11am) we’re pleased to be hosting a free online training event to help people learn how to develop apps in our low-code / no-code platform agileBase.

If interested, you can sign up here: https://www.eventbrite.co.uk/e/agilebase-intro-training-registration-101725178748

But what exactly is low-code / no-code? It’s becoming a common phrase in application development circles, so let’s step back and give a quick roundup of the main talking points and resources relevant to business decision makers.

Traditionally, software is created by developers – that means programmers, also called coders. For larger systems other roles also play a part such as the ‘system architect’ as well as specialists in say databases or user interfaces. Other parts of a team such as domain expert and project manager may also be present, but here we’re only considering the technical roles.

A no-code platform is software that allows people without these skills to create working software by abstracting away and automating the heavy lifting (low-code still requires some technical skills – see below).

It’s worth saying that although platforms are becoming very advanced (certainly ours is!) so no coding skills are necessary, there are still some skills or traits that do help – particularly creativity along with a willingness to think through the detail. We find accountants are often a good fit! It can also be a great career progression for people who do like to think through things in detail but haven’t had any formal programmer training.

We’ll now go through some of the main benefits and potential pitfalls, explain some common terms you may come across then explain where we fit in the ecosystem as a vendor.

If you’d like more detail, we’ll go through some real customer examples and see the technology in action during the session.

Benefits

For the details, a good starting point is always Wikipedia: https://en.wikipedia.org/wiki/Low-code_development_platform

Some key quotes are

‘A common benefit is that a wider range of people can contribute to the application’s development—not only those with formal programming skills. LCDPs can also lower the initial cost of setup, training, deployment and maintenance.’

‘Low-code development’s market growth can be attributed to its flexibility and ease.’

Other resources say

‘In a survey of Quick Base users, 68% said the main reason they create no-code apps is because they fit their organization’s needs better than other solutions, and 61% said it was so they can make changes more quickly to apps as their workloads and requirements change.’

That certainly rings true.

In our personal experience here at agileBase, we’ve found there is an emotional as well as a practical result. Customers who develop apps themselves feel more ownership of their systems, so find the ‘development’ experience enjoyable. Applications are friendly and easy to use and staff find that their input quickly results in improvements resulting in greater trust in the process.

That’s as opposed to the traditional outsourced model of bespoke software development, which can have a reputation for being slow, frustrating and in quite a large number of cases, just unsuccessful full stop.

Risks

There are criticisms of this model. Again Wikipedia lists the most common: 

‘Some IT professionals question whether low-code development platforms are suitable for large-scale and mission-critical enterprise applications. Others have questioned whether these platforms actually make development cheaper or easier. Additionally, some CIOs have expressed concern that adopting low-code development platforms internally could lead to an increase in unsupported applications built by shadow IT.’

Of course we try to tackle all of these objections. It’s not the subject of this article, but our Platform Vision for 2020 addresses many.

Some common terms

When reading about low-code / no-code, you may come across some terms commonly used.

  • Low-code / no-code’. Firstly, this term itself. What’s the difference between no code and low code? Some applications describe themselves as low code environments, others as no code.
    It is just what it sounds like – low code environments still require or allow a small amount of programming whereas with no-code platforms, everything is done with the graphical drag-and-drop interface.
    No code is becoming more common and if you’ve decided to buy a tool, it’s worth researching the pros and cons of each but at the conceptual level, we don’t think it’s a particularly important distinction.
  • Citizen developer’. This term refers to an employee or member of the public who is not a coder, but who through the use of a low-code / no-code platform, is empowered to develop applications.
  • Shadow IT’. The idea of a shadow government is a conspiracy theory that actual power lies not with elected representatives but with another group acting behind the scenes, sacrificing democracy.
    Shadow IT is not a conspiracy! But it does represent the belief that if the central IT department doesn’t control software development, consistency, security and governability are sacrificed.

The shadow IT concern is legitimate and this is an area of much discussion. However it’s not necessarily a win-lose situation for either side. Hopefully all stakeholders can come to a shared understanding of how to manage low-code / no-code development in a way that benefits all, raising IT’s role to governance, strategy and process management.

The software itself should address these concerns head on. For example, roles and privileges can determine exactly who can do what. Reporting and automated alerts can highlight which people are using the system how and when.

agileBase as a low-code / no-code platform


There are an increasing number of tools and platforms in the market, a web search will bring up handfuls. 

What sets us apart as a vendor?

Our strength is in building web based ‘back offices’ for businesses. Other tools focus on consumer-facing or native mobile applications.

Our USP is, simply put, we can scale with the growth of an organisation. We sometimes say “from startup to scale-up without screwing up”. 

Many tools are aimed at one size of company or another. There are those for startups and one-man bands to quickly build tools to suit their specific needs. Then at the other end of the scale, those for large businesses which are often more complex to comprehend.

agileBase is fast, friendly and flexible when getting started at a small scale, but as our platform is based on a powerful enterprise-class database and other open source software, we can scale to support high-throughput scenarios and many users.

Built in security features such as mandated 2FA and fine-grained control over data exports support large scale use.

The powerful API allows close connections with third party software such as finance or ERP systems, with agileBase acting as the engine to power all the data.

Other elements of our business such as our pricing policy also support this.
We’d love to welcome you to the event or just hear from you.

Updates

In these unprecedented times, work continues here at agileBase (from our homes). 

Whilst it’s not on the top of most people’s agenda, we do have a new release going out so I thought we should let you know the details so they aren’t a surprise. In brief…

Emailing documents

There’s a new feature to allow easy emailing of documents uploaded to agileBase to co-workers or outside people (e.g. customers) who don’t have a login.

Next to a document, click the email button. You can then click ‘add recipient’ to choose a recipient, or manually enter an address. The system will let you choose from contacts it finds in your database.

Logging changes to locked fields 

When unlocking a field to change the value, the system prompts you to enter a comment. It now automatically pre-populates the prompt with the value you’re changing from, to make it easier to see what the change was. You can add your own comment too.

Intelligent colours for charts

Do you notice anything strange about this graph? Experience any cognitive dissonance?

From now on, agileBase will colour breakdown charts based on the categories. Words like red/amber/green, hot/cold, done/in progress/overdue will be coloured appropriately. Other words will continue to be assigned random colours. If you have any words that you’d like special colours for, please let us know.

Bugfixes

We’ve tweaked lots of other things too small to notice every day but which should make the system run more smoothly.

That’s all for now. We wish all the best to all our customers, stay safe.