As we reach the end of 2024, there's a few things we want to let you know about before the holidays start.

API authentication deprecation 🌇

Back in July, we announced that Alloy's API authentication will only accept bearer tokens starting from next year. Therefore, this is one last reminder that token headers and token URL parameters will no longer work as of early January 2025.

If you haven't already, please update any integrations or tools you use accordingly!

Mobile developer account transfer 📲

As part of some new year housekeeping, we'll be transferring ownership of the Alloy Mobile app to new Causeway developer accounts on both the App Store and Google Play Store.

Don't worry, this won't affect Alloy Mobile's availability on either store! You won't need to reinstall the app and any unsynced data should be unaffected.

However, there may be some minor side effects:

• If you use your fingerprint to sign in, or rely on saved passwords, you may need enter your account details again.
• You may need to re-grant permission for Alloy Mobile to access your device's camera, gallery and location.

The developer transfer will be performed in January 2025. In the unlikely event that this causes any issues, please contact Support for assistance.

Alloy Mobile iOS map behaviour 🗺️

We will be improving the behaviour of the map in Alloy Mobile iOS:

• When selecting an item, the transition will be smoothly animated instead of abruptly jumping to the item.
• Selecting any part of an item's geometry will select the item. The map will pan and zoom so that the item's entire geometry is visible.
• With an item selected, selecting a marker on that item will zoom the map to that marker.
• If multiple item geometries overlap a location, selecting that location will cycle through those items.

Nothing too drastic but just so you know what to expect! These changes will be implemented in Alloy Mobile v2.66 on 9th January 2025. If you experience any issues with the new behaviour, please contact Support.

To interact with Alloy’s API, you must include your personal API key in every request you send. Currently, there are three possible methods for doing this. However, two of these methods can potentially expose your API key to attackers.

Therefore, we’re announcing the deprecation of these insecure methods, which will be blocked entirely from January 2025.

Going forward, please use the bearer authentication scheme to communicate with Alloy.

Who will be affected?

All users and implementations that don’t use Bearer authentication to access the Alloy API.

Details

The following authentication methods are now deprecated. They continue to work for now, but will no longer be accepted in the near future:

• A token URL parameter:
  https://uk.alloyapp.io/api/session/me?token={value}

• A token header:
  Token: {value}

From now on, the only supported method is to use the Authorization header with the bearer scheme (RFC 6750):
Authorization: Bearer {token}

Expected release

January 2025

The ApplicableTypes API endpoint (Swagger, ReDoc) can add and remove associations between specific activity designs and asset designs.

We’re updating this endpoint so that you can perform multiple “Applies to” operations in one go. This’ll make it possible to associate multiple work items with multiple jobs in a single API call!

However, the update will introduce a minor breaking change to prepare for.

Who will be affected?

Users and implementations that add or remove applicable types via the Alloy API.

Details

The following endpoints have a from parameter that currently accepts a single ApplicableFromWebModelBase model:

• Add applicable types – POST /api/applicable-type
• Remove applicable types – DELETE /api/applicable-type

After the release date, the from parameter will require an array of ApplicableFromWebModelBase models, even if you’re only supplying one.

Expected release

25th July 2024 as part of the Alloy v2.61 release.

Things are starting to look a little different around here. This month’s update took place during the evening of the 30th May. For a full list of changes in v2.59, please visit the Alloy Changelog.

New logo ⚡

Alloy has rocked the same logo since its inception in 2017. The big, bold letters represented our desire to make an impact and disrupt the marketplace with a similarly big and bold product, making it possible to manage all asset classes in one place for the first time.

Seven years later, Alloy is now one of multiple products offered by Causeway Technologies, the UK’s largest software solution provider for the construction and infrastructure industries.

Following the recent announcement of the new CausewayOne platform, our products are being rebranded with a new visual identity that’s modern and consistent. The new logo represents Causeway’s ongoing mission to digitise and connect each stage of the construction process, enabling data to flow freely between them.

We hope you like the new look!

Responsive Geometry Editor and pickers ↔️

We’ve been gradually improving Alloy’s usability on devices with smaller screens.

The Geometry Editor now renders properly at low screen widths, with the Draw tools appearing at the top to avoid collisions with other buttons. The GeoJson panel is no longer shown by default, but can still be enabled via the bottom-right menu if needed.

Similarly, the colour, icon and calendar pickers have also been adapted to work on smaller screens. In particular, the arrow buttons on the side of the calendar picker have moved to the top blue bar, enabling you to cycle through the months and years.

Renamed Parents section on Mobile 👪

When viewing an item’s details in Alloy Mobile, the “Originates From” section has been renamed to “Parents” to match how it appears in Alloy Web.

Access policy changes ✅

While we don’t often mention API-only features in release notes, we know some of you have started implementing access policies to govern user access on a per-item basis.

Therefore, we thought you might like to know about a couple of recent changes!

First, we’ve added three new expression types, providing more ways to define an access rule. To learn about how they work, check out HasAccess, User condition and Boolean condition in this Alloy Help article.

Secondly, access policies are now supplemental to permissions, rather than functioning on their own. If a user doesn’t have the Read permission enabled for the item’s design, an access policy will no longer have an effect.

Put simply, permissions let you grant access to all items of a particular design. Access policies let you refine that access by making it conditional, based on whether an item’s values fulfil the defined condition(s).

We’re updating the behaviour of AQS Join queries to ensure that all join attributes are exported correctly in a particular scenario.

This will change the output of the Export API endpoint for some AQS Join queries. However, rest assured that none of your saved queries will be affected!

Who will be affected?

Anyone who uses:

• the Data Explorer’s export feature in Alloy Web
• the Export API endpoint

Details

The change will only affect AQS Join queries where all the following are true:

• the queried design contains a Link attribute to an interface
• the query includes a join attribute from the interface
• the query includes one or more join attributes from a child design/interface that implements the interface

Currently, in this scenario, the join attributes from the child design/interface are incorrectly included within the interface’s path group. As a result, these join attributes are omitted from the export files because their paths are invalid.

The change will correct this issue. Therefore, if you regularly export joined data, be aware that export files may start to contain attributes that were missing before.

Expected release

30th May 2024 as part of the Alloy v2.59 release.

Whenever a workflow triggers, a run log is created to record a summary of the actions performed and the items involved. By default, these logs are stored indefinitely.

However, after several years of unchecked growth, the logs now occupy over a terabyte of database storage! This in turn produces larger indexes that consume extra server memory and generally slow things down.

As these log files are rarely viewed past a certain point, we've decided to implement a sensible default retention period that should cover most requirements:

• Manual and Event workflows - 14 days
• Schedule workflows - 45 days

This will improve the health and performance of Alloy for everyone.

Who will be affected?

All customer projects that have ever run a workflow.

Details

After the release date, all workflow logs older than 14/45 days will be routinely deleted. This will affect both new and existing workflow logs.

Set a different retention period

It remains possible to set the retention period of individual workflows via the Alloy API.

When creating or editing a workflow via the Workflow endpoint, you can supply a value for the optional logsRetentionDays parameter. For more detail, see ReDoc / Swagger.

Expected Release Date

The end of January 2024.

By default, Alloy uses a simple Helmert transformation when converting geometry from the British National Grid coordinate system (EPSG:27700) to WGS 84 (EPSG:4326). This works well most of the time and requires no user input.

However, it can result in slight misalignment in a handful of cases, and we do like to give you choices where we can!

Therefore, as of the October 2023 update, you can now specify a grid shift file for a particular transformation (e.g. OSTN02, OSTN15) when importing or exporting geometry data via the API.

To use a different transformation, first upload its grid shift file to Alloy. The max size is 100MB and the supported formats are:  GSB, LLA, DAT.

Using the API

When using the Alloy API to import or export data, just add +nadgrids= to the proj4 string (where is the Item ID of your uploaded grid shift file).

When importing data using the ImportSettingsDataWebModel, you can specify the proj4 string as part of its geometry property.

When importing NSG/NLPG data using one of the two ImportSettingsStandardFormatWebModels, no proj4j string is specified. Instead, you can populate its gridFileItemID property with the Item ID of the grid shift file.

Using Alloy Web

When configuring a custom import in Alloy Web, you can configure the Geometry in step 3.

After choosing the Type, select the magnifier icon in the Coordinate system field and choose one of those listed. This populates the field with a proj4 string, which you can then suffix with +nadgrids=.

Access policies are back, baby! Use them to enforce item-level access control.

Back in February, we announced that access policies were being temporarily removed, with a new implementation coming in future. They originally worked by tracing paths between the user and the item they were trying to access. In practice, the performance cost was too high, so we took them back to the drawing board.

We're pleased to announce that the new implementation of access policies has now arrived!

How do they work?

You can create one or more access policies for a particular design/interface. Each access policy can have one or more rules.

A rule applies to one or more user groups. It grants them conditional read access to items of that design/interface, based on the value each item has for a given attribute/property.

Currently, access policies can only be created and managed via the Alloy API.

What are they good for?

Access policies are enforced throughout Alloy. If a user isn't granted access to an item, it won't appear for them, regardless of whether they're using the map, the Data Explorer, etc.

This lets you control which items appear for which user groups. For example:

• The "Emergency" group can only see tasks whose Priority attribute is "High" or "Critical".
• The "Waste Sector C" group can only see waste jobs whose Geometry attribute is located within a specific area.
• The "Acme Contractor" group can only see assets whose Default Team attribute is set to one of their teams.

What about Permissions?

Access policies are designed to work alongside Permissions. Think of them as a more granular replacement for the Read permission.

If you enable the Read permission on a design/interface, it grants read access to all of its items.

Alternatively, you can disable the Read permission and use access policies to grant conditional access to items, based on the values they hold.

Learn more

To learn about creating and managing access policies via the Alloy API, see Access Policies on the Alloy Help site.

Please note: the relational expressions will become available on 30th November, as part of the Alloy v2.53 release.

Overview

A workflow action group lets you define a series of actions that can be stored on its own and referenced in other workflows. A workflow within a workflow, if you will.

However, now that manual workflows have parameters, they can provide this functionality in a better way. Therefore, for simplicity and consistency, we're removing workflow action groups and updating manual workflows so they can be referenced within other workflows.

Who will be affected?

Users who create and edit workflows via the Alloy API.

Details

You'll be able to reference a manual workflow in your workflow by creating an action whose design implements designInterfaces_workflowManualTrigger:

• The parametersDesignCode property must be set to the design code of the manual workflow.
• The new OutputActionId property must be set to the ID of the action that represents the final output of the referenced manual workflow. This output will be passed on to the next action in your workflow.

While it will be possible to chain multiple workflows (a workflow that references a manual workflow that references a manual workflow...), rest assured that Alloy will stop you from creating any circular references! 😮‍💨

Parameters

If the referenced manual workflow requires any parameters, you can supply them in the parameters array when adding/editing the relevant action in your workflow.

Depending on the type of WorkflowComputedItemAttributeWebModel used, you can supply values computed during your workflow, or pass on any parameter values that were supplied to your workflow when triggered.

Removed endpoints

All WorkflowActionGroup endpoints will be removed from the Alloy API.

Expected Release Date

26th October 2023 as part of the Alloy v2.52 release.

Overview

In the Report Builder, you can create an Item data source to represent the attributes and properties of a particular item, and an AQS data source to fetch the attribute data of multiple items.

You may have tried to use an Item data source as a parameter within an AQS data source, e.g. to fetch the defect items raised against that item. Currently, this doesn’t work because the Item Id header of the Item data source is a Text type, which isn't directly comparable with actual Item IDs.

Therefore, we're changing the Item Id header type from Text (string) to Link (AlloyId[]) to make this possible!

To accommodate this, a few other changes will also happen.

Who will be affected?

This will affect report builders wishing to use an Item data source as a parameter within an AQS data source.

Details

The Item data sources in everyone's custom reports will be updated with this change automatically.

However, any existing AQS data sources containing an unusable parameter as described above will still throw an error (1586360664 - Parameter type String cannot be used in node of type AlloyId). To fix this, simply recreate the parameter.

No more sorting by Item Id

After this change, it will no longer be possible to sort by the Item Id header on any data source. Doing so will throw an error (1603203353 - Ordering is not supported on the following type AlloyId).

Hardly anyone has attempted this, so we don't envisage it causing issues going forward.

More flexible joins

To create a Join data source, you must select a header from each of the two data sources you wish to join. Currently, you can only join headers of the same type (or a Link type to a Text type).

After this change, it will be possible to join a Text header to any other header type and vice versa. The other header type will be "stringified" for comparison.

AQS statistics constraints

AQS statistics data sources contain two headers to represent the data returned by its query. The Key header is a Text type and the Value header is a Number type.

After this change, API users will be able to specify the type of these headers via two new optional properties:

• KeyConstraint - corresponds to the attribute being grouped on, so can be set to any attribute type.
  
  
• ValueConstraint - corresponds to the aggregated values of the attribute being queried, so can be set to Number, DateTime or GeoJSON.

These can be declared within the relevant request model when using the /api/custom-report/{customReportCode}/data-source endpoint to add (Swagger/ReDoc) or edit (Swagger/ReDoc) an AQS statistics data source.

This will be useful for creating joins in some scenarios.

For example, imagine having an AQS statistics data source that counts Waste Containers grouped by type, and an AQS data source that fetches items of the Waste Container Types design.

To create a Join data source from these, you would select the Key header (String) of the first data source and the Item Id header (Link) of the second data source.

By default, the Item Id header will be stringified for comparison with the Key header, so the join should work. However, you can set KeyConstraint to "Link" to ensure an accurate comparison.

Expected release

29th June 2023 as part of the Alloy v2.48 release.