Skip to main content

Platform Upgrade: What’s Changing in Spanner

We are upgrading Beacon’s infrastructure to improve speed and reliability, migrating away from a database powered by Amazon RDS to one powered by Google Spanner. Here is a summary of the changes you will see across the Beacon platform.

New people search bar

The most noticeable change is the new people search bar at the top of Beacon:

When you click/tab into this, you can see your recent searches and people you've recently viewed.

You're able to search by people's names (with spelling mistakes included), emails, phone numbers, and record ID (Beacon's internal ID).

Matching records are displayed with a preview including the primary email, primary phone number, primary address and record ID

You'll also notice that we highlight the text that matches as well.

While primary addresses are displayed in search result previews, searching by address isn’t supported in the top menu search. Searching or filtering by address can be done on the People list view.

Sorting

Sorting limitations & directions

In order to ensure that sorting is lightning fast, we have made changes to optimise what you can sort by in Beacon.The table below shows how this now works:

Field Type

Sortable?

Boolean (checkbox)

No

Currency

Yes

Date

Yes

Drop-down list

Yes

Email

Yes

File

No

Location

Yes

Long text

No

Number

Yes

Percent

Yes

Person name

Yes

Phone

Yes

Point to another record

Yes

Rating

Yes

Rollup (first/last)

Yes

Rollups (count/sum/average)

Yes

Short text

Yes

Smart field

Yes

URL

No

User (ID)

Yes

Now, we handle Blank (Empty/Null) results by always putting them at the end when in descending order.


Previously, we were inconsistent depending on the field type.

Records with the same value, including empty ones, are shown newest first (same as before)

Sorting large amounts of data

If your view contains over 100,000 records, Beacon will only sort by 'Created date'.

You can apply a filter to narrow your dataset (below 100k) if you need to sort by a different field.

Large limits on some field types

Previously, there were no limits on fields that allowed multiple entries (Email, Location/Address, Phone Numbers, Point to another record fields, etc.).

Now, fields support a maximum of 1,000 items per field. If you need to track more items than this, we recommend using a linked record type (for example, using 'Campaign Members' records linked to a 'Campaign' record).

Filtering on dates

Previously, when using the "Days before" and "Days after", these would include all records, even those older/newer than now... This confused a lot of people, for instance:

  • "Days after 2 weeks ago" would include anything that was also set in the future.

Now, relative date filters automatically set 'today' as the upper boundary, preventing past-focused queries (like 'Days after 2 weeks ago') from including future dates.

Contains changes

We have now added a 3-character limit to contains to ensure the response returns very quickly.

Suggested duplicates

Beacon now searches for duplicates in real-time, replacing the previous 15-minute interval check

Creating fields with defaults or updating fields with defaults

These actions are now highly optimised. Beacon will display a 'loading...' indicator while processing, allowing you to continue your work without waiting.

Number fields now have decimal place limits

Number fields now support up to 9 decimal places to ensure consistent formatting across calculations.

Creating related records

Previously, when you created related records, Beacon would do a large number of additional tasks (Rollups, Smart fields, Workflows, etc.) which would slow down the creation. To improve creation speeds, when you create a Related Record from an individual Record page, Beacon now shows the new record in a section at the top instead, in a new "Just Created" section (and it does the additional tasks a few seconds later)

Searching is now much smarter

Handling accents

Previously, searching for alternative spellings or special characters was not easy and would require workarounds. For instance, searching for "Amelie" would not find a person named "Amélie" (notice the accent).

Now, accents and special characters are handled in search without requiring workarounds like wildcards - so now searching for “Amelie” will find “Amélie”.

Searching names

Previously, searching “David Simpson” would not find a person named “David James Simpson” unless you included a wildcard in your search term (”David % Simpson”).

Now, searching "David Simpson" will find people with that first and last name regardless of middle names. It would also find someone with first name "Simpson" and last name "David".

Searching long text fields

Previously, when you searched, Beacon would look through long text fields the same way as short text fields. This caused problems for short search terms; for instance, searching "comp" would find words like "complete" and "complementary".

Now, when Beacon searches long text fields, it performs an exact match, so if you search "complete", it will now return if the long text has "complete" but not "completely". This should lead to better results.

You can still use Filters to be more generic if you would like.

Removal of wildcards

Wildcard characters in search are no longer supported in Beacon. Previously, you could use % (multiple-character wildcard) or _ (single-character wildcard).

Some people used the % to search for the possibility of a space; for instance, if you're doing data cleaning, you might use "% %" to reveal a space is there. Instead, you can use a smart field to do this:

=IF(LEN({{{name.full}}}) <> LEN(SUBSTITUTE({{{name.full}}}, " ", "")), TRUE, FALSE)

Search Ordering

Previously, when you searched, we would order based on which field you were sorting by before the search and allow you to change the sorting direction after a search.

Now, because our search is smarter, we sort by relevance instead, making it easier to get to the specific record you are looking for inside of your filter. You aren’t able to change this from relevance.

Postcodes

Previously, when filtering on specific Districts (W2) or Areas (W) for a postcode, you'd often have to use a wildcard to do this, for instance "W%".

Now, there is a new filter option to make filtering by partial postcodes much easier:

When you filter on a Postcode, you can now select Area (SE), District (SE2) or Region (which is a combination of postcode areas).

In Area, you are able to search not just for the letters, but also the city/area they are in:

Very similar for region:

However, searching in District requires the specific letter and number combination, i.e. "WC1" and "SE2".

With this new feature, you no longer need to use the wildcards like "SE1 %" to filter for specific postcodes.

Note: Postcode Regions group nearby areas for broad filtering; exact geographic or administrative boundaries may occasionally overlap.

Timelines of records

These are now more useful, helping to show you not just custom but default states for records when they were created:

  • Beacon will now show on record creation in the Timeline:

    • All Checkbox values (even if not selected)

    • All Default values if set

  • Beacon will no longer show on record creation in the Timeline:

    • Rollups (as these are dynamic, and thus are misleading)

Exporting

There is a slight change in how dates are outputted in Exports now:

Column type

Now

Previously

Custom date fields

Account timezone

Account timezone

Core timestamps (created_at etc.)

Account timezone

UTC

Workflows

If a workflow action attempts to set an unsupported value in a field on a record, Beacon will now create/update the record and skip only the unsupported value, rather than failing the entire workflow.

This should help you to diagnose issues and ensure data is not lost.

Guide for large accounts

If you have more than 100k contacts, we have written this guide on how to optimise for our new system.

Developer API changes

Note for developers: The following changes affect API payloads and webhooks.

Files are now hosted on Google Cloud Storage rather than Amazon S3

Previously, you would see a response like this:

{
  "id": "9b9061c5-e393-4872-a619-432b90acc1f3",
  "infected": "clean",
  "name": "export-payments-1776780699217.csv",
  "size": 8815837,
  "source": "upload",
  "type": "text/csv",
  "url": "https://beacon-user-uploads-staging.s3.eu-west-2.amazonaws.com/account/....etc"
}

On top of the URL being different, you'll also see that our Virus scanning has changed from "infected" to "scan_status" to be a bit nicer, as well as the possibility of a preview URL for images.

An example response now is this:

{
  "id": "31f8a3dc-8f94-4d7a-baad-94b9f00a8197",
  "name": "export-payments-1776780699217.csv",
  "preview_id": null,
  "preview_url": null,
  "scan_status": "clean",
  "size": 8815837,
  "source": "upload",
  "type": "text/csv",
  "url": "https://storage.googleapis.com/entities-service-files-clean-staging/account/....etc"
}

API response cleanup

DataSource is no longer returned, nor are latitude and longitude for locations (addresses). Beacon now does this in real-time for addresses rather than caching them.

Data Warehouse

Previously, Data Warehouse was a “view” on the data stored inside of Beacon. This required you to create your own table on this view to be able to access it. It also meant that any updates to your Beacon Database structure required a manual update on our side.

Now, Data Warehouse is a periodic copy of your data into a “table” (Every 15 minutes). This means you can point your Visualisation, ETL or SQL directly at the table instead, without the permissions problems. It also means that changes are pushed through with the next sync.

Related Articles
Did this answer your question?