Clients on Journeys can now set an expiration time for step up nodes to help reduce abandonment rates for step up verification. The timer tracks how long an applicant has been at the step up node. If the timer expires the user continues down an expired branch but if they complete step up before the timer they progress through the Journey as normal

To get started, navigate to your chosen Journey, click the ellipses on the step-up node and select “Set Expiration”. You can then set an expiration timeframe before hitting ‘Save’.

The What-If Analysis Testing results page has been updated to include: 

• a new summary section which displays things like the changes made and a table view into the outcome distribution
• Outcome rates on top of the bars in the graph to easily visualize the outcome rates before and after changes were made
• New filters to filter for original and test evaluations based on outcomes and tags.

Alloy now supports string outputs to better accommodate more complex credit policies and make the outputs more readable and accessible, minimizing client dev work.

String datatype can now be used as a possible output for:

Matrix Models

• When you’re setting up a Matrix Model, you’ll now see 2 datatype options from the drop-down. One of them will be “string”: this is referring to the cell outputs, not the axis header datatypes (note: those do not have to match the datatype of the cells).
• You can now edit the datatype of a Matrix Model after you create it - hit “Edit Matrix Model” from top right of the Edit panel.

Outputs Attributes

• When you’re creating a new Output Attribute, you’ll now see our new Attributes panel. You’ll see there are now 3 datatype options: Integer, Decimal, and String.

You should be able to create & use your “string” type output attribute in same way as integer-type that you are used to, except that you are limited to only 1 thing inside of the expression, and you can leave it empty (we’ll just return null in the API response if you do). You cannot use any of the math operators, of course! Just add 1 thing and that’s it. You can use JQ, however.

Both codeless SDK and legacy SDK users can now autonomously create keys directly in the dashboard. 

Clients will also be able to see all available device and behavioral risk service settings on this page.

Codeless SDK users can also associate keys with Journeys to allow them to have different customization options for different Journeys (i.e. one Journey is for onboarding and one is for credit underwriting so the outcome screen text differs). 

To get started, navigate to Settings > SDK where you’ll see the updated SDK page.

Clients on Journeys will now see an ‘Archive’ button to help for all action nodes (including custom Review nodes), that will show a new warning modal, listing all of the active Journeys which that action is used in. This will help reduce potential errors when making changes to your Journey.

We have also added a new Journey Builder Validation error in the journey graph on the archived action nodes, so that they will be easy to spot. This will also ensure you won't be able to set a new journey version active or clone it if it contains archived action / Review nodes.

Clients on Journeys can now test their policies end-to-end to validate that they function as expected and that they’re receiving the desired outcomes.

A multi-environment configuration will allow clients to specify the credentials or sandbox settings for each service used within a Journey version. Additionally, outcomes can be set for action and step-up nodes to auto-complete these steps since a user action is required in a real life setting.

To get started, you can access the Multi-environment Configuration through the Journey’s Testing Suite.

Clients on Journeys will experience a new versioning paradigm that brings enhanced flexibility and better visibility and audibility into logic changes within their Journeys. 

-The main change is the introduction of “Version pinning”, which ensures that a Journey version, once saved, is frozen in time with the workflow versions contained within it. Any subsequent logic changes in the new workflow version will result in a new Journey version to ensure those changes are captured in a more auditable way. (As a reminder, before this release, the active version of a Journey automatically used the active versions of the workflows contained within it, and workflow logic changes did not increment the Journey version.)

The key changes you’ll see in the dashboard are:

-When activating a workflow version (from either the workflow versions list or from the workflow builder itself), you'll now see an updated modal that lists all Journeys containing that workflow when activating a new workflow. This updated modal gives you more flexibility by allowing you to choose the appropriate action for each Journey, whether it's setting the new version as active, creating a draft version, or doing nothing (note that the default option will be different depending on whether errors would be introduced into the journey graph with the workflow change).

[Insert image #1 from release note]

-When swapping workflow versions in Draft Journeys, you’ll see that non-active versions are clearly highlighted with an orange outline, and an informational modal will alert you if a Journey is using non-active workflows. 

[insert images #2 and 3 from release note]

-Once you then go and try to set this Journey active, after activation, you will now see this new informational modal, alerting you that the journey is using non-active workflows. 

[insert image #4 from release note]

You can optionally go and set these workflows active if needed, but remember that the new paradigm does not require it. All that “active” means now is that it will become the “default” workflow version that would be added to a journey if you were to add the workflow from the “+” menu on the journey builder.

We’ve enhanced our auto-assign capability to give more granular permissions for a particular Role to only review entities that are in particular Review node type (e.g. a custom Review node, or a Manual Review node) to better accommodate different types of review processes and team structures.

This means that clients can now restrict certain (e.g. more junior) Role types to reviewing entities in only a subset of Review types, while more senior roles can float between queues and/or review JA as a whole.

To get started, navigate to Settings --> Roles and specify the Review node types (including the standard “Manual Review” node) for each of those Roles you set up. Multiple roles can have same Review node types selected. The default is “All Review nodes”.