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 add a Repeater control to a flow document's layout that iterates over a specific header of a given data source. When the report is run, any "child" controls inside the Repeater control will appear once for each iteration.

Currently, the child controls within a Repeater control are automatically arranged in a vertical formation. However, depending on the data being repeated, this can lead to unnecessarily long documents containing lots of pages.

Therefore, we're making it possible to stack repeated content horizontally - by placing the Repeater control within a Horizontal stack control!

Who will be affected?

This will affect new and existing reports containing Repeater controls.

Details

Repeater controls at the root of a flow document will be unchanged.

However, if a Repeater control is placed within a container, the appearance of its child controls will be determined by that container. This means that:

• A Repeater control within a Horizontal stack control will now repeat horizontally.
• A Repeater control within a Vertical stack control will continue to repeat vertically.
• A Repeater control within a Repeater control will behave according to its parent control.
• The Repeater control's Margins and Relative Width won't be applicable.

Initially, repeated content will only appear horizontally when the report is run. The Document Layout Editor will be updated to reflect this new behaviour in the subsequent Alloy release.

Wrap child controls

As flow documents typically use portrait orientation, it's important for Horizontal stack controls to have their Wrap child controls property set to Yes when appropriate. Otherwise, their child controls may go off the page!

Therefore, to ensure that any newly-horizontal content remains visible after the change, we recommend checking your custom reports for any Repeater controls within Horizontal stack controls and configuring them as above.

Expected release

29th June 2023 as part of the Alloy v2.48 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.

We're pleased to announce that Alloy Help has received a beautiful makeover this week 💄.

The website has been rebuilt from the ground up to be bigger, bolder and easier to navigate.

Content now appears larger and fills more of the screen, making it clearer and more comfortable to read. The left sidebar can group articles more effectively for better browsing. A handy Table of Contents appears on the right, which displays an outline of the current article and your position in it, and lets you jump to a particular heading.

There's even a Dark Mode for some gentle night-time viewing 🌙.

This forms part of ongoing work to improve the quality and readability of Alloy's documentation, so you can find and absorb information when you need it.

To check it out, visit help.alloyapp.io or select the bottom-right ? icon in Alloy.

Overview

With the April 2023 update comes the ability to specify parameters for manual workflows, enabling the workflow to take input from the user that triggers it!

This new feature is currently only available in the Alloy API but will appear in Alloy Web soon (look out for it in upcoming release notes 👀).

Start by creating a design with the desired parameters represented as attributes. When you create the workflow, you can now specify your parameter design in the trigger model. You can then reference the parameters by their attribute codes when configuring the workflow's actions.

When you trigger the workflow, you can specify which parameters to use and supply any required values. Once the feature comes to Alloy Web, users will be prompted to enter values for all parameters defined by the parameter design when they trigger the workflow.

Parameters greatly increase the flexibility of workflows, to the point where a single workflow can now cater for multiple circumstances that previously required setting up multiple workflows. We look forward to seeing how you use them!

Who is affected?

This change provides new opportunities for workflow editors when designing and implementing manual workflows via the Alloy API.

Details

Here are the steps for setting up a manual workflow that takes parameters via the Alloy API.

Create a parameter design

• Create a design that implements the designInterfaces_workflowManualTrigger interface.
• Add an attribute for each parameter you plan to use.

Create a workflow

• Create a workflow via the /api/workflow endpoint (Swagger/ReDoc).
• For the trigger property, specify a WorkflowTriggerWebModelBase with a discriminator of ManualTrigger
• For the parametersDesignCode property, enter the code of your parameter design.

Use a parameter in an action

• Add an action via the /api/workflow/{code}/action endpoint (Swagger/ReDoc).
• For the parameters property, specify an array containing at least one object with a discriminator of WorkflowComputedItemAttributeWebModel.
• For the value property of the WorkflowComputedItemAttributeWebModel object, specify an object with a discriminator of WorkflowSyntaxNodeTriggerParameterWebModel.
• For the parameterCode property of the WorkflowSyntaxNodeTriggerParameterWebModel object, specify the relevant attributeCode from your parameter design.

Trigger the workflow

• Run the workflow via the /api/workflow/{code}/manual-run endpoint (Swagger/ReDoc).
• For the triggerParameters property, specify the relevant attribute code from your parameter design and optionally provide a value.

Overview

For those of you using Alloy to interact with the government's Street Manager service, an important transition is coming up.

In May 2022, the Department of Transport released v4.0 of the Street Manager API. Since then, they've continued to maintain endpoints for both v3 and v4.

While v3 isn't being decommissioned until May/June 2023, the legislative changes in v4 will come into force on 1st April 2023, effectively compelling all users to make the switch.

Therefore, we're updating Alloy to support the current v4.15 specification ahead of this deadline.

Who will be affected

This change will affect anyone using Alloy Web or Alloy Mobile to interact with the Street Manager service.

Details

Fortunately, there are only a few changes to learn about!

New permit conditions

• NCT09d - Changes to traffic management arrangements APPLIES TO ALL MAJOR PERMITS on Category 0, 1, and 2 streets only.
• NCT03 – Activities ancillary to those permitted – supplementary information.

For more detail, see the Statutory guidance for highway authorities.

New Traffic Management type

A new TM Carriageway Restriction Type will be available: Temporary obstruction 15 minute delay.

Footpath Closure

A new Foothpath Closure attribute will be mandatory for all permit requests.

Emergency Contact Name and Number

New Emergency Contact Name and Emergency Contact Number attributes will be optional for most permit requests, unless the chosen Traffic Management type is Multi Way Signals or Two Way Signals.

Expected Release

30th March 2023 as part of the Alloy v2.45 release.

As we reach the end of the year, it's time to look back at what we've all accomplished together in 2022. Liz and Kwarti, you can sit this one out... 😬

You loved it last year, so here it is again! We've put together a fancy webpage that you can log into to see all kinds of stats about your year in Alloy, delicately interwoven with the eccentric humour you've come to expect from us 😅

So go on, visit review2022.alloyapp.io and marvel at how busy your organisation has been this year. Feel free to share the URL of your personalised report with someone you want to impress, such as your boss or a prospective dating partner. Here's what Matthew McConaughey had to say about ours:

On behalf of the Alloy team, thanks for being with us in 2022, and we look forward to making 2023 even better 🎉

Overview

Alloy’s robust Permissions system gives you fine control over who has read/write access to most of the objects in your Alloy database (e.g. designs, layers, workflows).

To take this a step further, we introduced Access Policies. These are simple rules defined per design/interface, which ensure that users can only access items that can be traced back to them. For example, making job items only accessible to users who are members of the job’s allocated team.

While Access Policies work well in principle, the current implementation unfortunately comes with too much of a performance cost.

Therefore, Access Policies will be removed in the next Alloy release, to be replaced with a better implementation at a later date.

Who will be affected?

No active customers are currently using this feature, so we expect its removal to have zero impact.

Details

The /api/access-policy/ endpoints will be removed from the API. Any remaining access policies will be deleted.

Expected Release Date

23rd February 2023 as part of the Alloy v2.44 release.

Overview

Back in December 2021, we announced that the mechanism for API keys would be changing.

In summary, API keys would no longer be generated automatically for every user, so new API keys must be generated on demand. Additionally, these new API keys must be passed using the OAuth 2.0 Bearer token format. For full details, please see the previous New API Key Management announcement.

These changes were implemented on 13th January 2022, with the old API keys remaining valid for a year.

Therefore, this is to remind everyone that the old API key mechanism will be removed in January 2023!

Who will be affected?

Any user or integration that still uses an old API key to communicate with the Alloy APIs.

Details

As of the release date below, old API keys that were created before 13th January 2022 will no longer be valid.

Additionally, the /api/user/me endpoint (Swagger/ReDoc) will no longer include the old apiKey property in its responses.

To learn about the new endpoints for managing API keys, please see the previous New API Key Management announcement.

How can I check my API key?

The simplest way to check if your API key is "old" or "new" is to consult your code. Does it pass the API key in the OAuth 2.0 Bearer token format (RFC 6750)? If so, your API key is new!

Alternatively, you can use the GET /api/user/me endpoint (Swagger/ReDoc) before the release date to return information about the currently logged in user. If your API key matches the value of the depreciated apiKey property in the returned user, your API key is old.

If in doubt, we recommend using the POST /api/api-key endpoint (Swagger/ReDoc) to create a new API key.

Mesh Users

If you have any workflows that use a Call Mesh action, your Alloy customer project will need updating with a new API key. We've been reaching out to customers we believe to be affected by this, but if in doubt, please contact Support to request this.

Expected Release Date

26th January 2023 as part of the Alloy v2.43 release.

Overview

This is to inform all users that we've recently implemented three safety limits to Alloy’s engine.

These have been put in place to help ensure that the performance, reliability and security of Alloy remains high. Rest assured, these limits have been calculated carefully, so most users will never reach them!

In rare cases where a limit is reached, users will receive a detailed error message to inform them what has happened, so the situation can be avoided in future.

Who will be affected?

These limits affect all users of Alloy but will be unnoticeable by most.

Details

The following limits have been added.

Maximum Background Tasks

The number of background tasks that can be queued per customer project. This has been limited to 100,000 tasks, which is far higher than has ever been reached before.

If the limit is reached, attempting to create a task will fail with this error:

Error Category: ResourceLimited,  Error Code: 1657552956

Maximum Item Size

The size of any item being operated on. This has been limited to 2MB (roughly 420,000 words of text) for optimal resource management.

If the limit is reached, the operation will fail with this error:

Error Category: ItemSizeExceedLimit, Error Code: 1657279454

Maximum Items to Query in Bulk

The total number of items involved with any write operations. While a query may only affect a moderate number of items directly, each item may have child/parent items that need querying too. Therefore, this has been limited to 200,000 items on the Task Executor (75,000 items on the API services).

If the limit is reached, the query will fail with this error:

Error Category: BulkQueryLimitExceeded