Journey: A Journey is a decision configuration that allows you to run multiple workflows or steps.

Journey Application: The act of an entity or group of entities traversing the configured journey graph.

For example, your business wants to offer a credit product that required two logical steps configured as Workflows within Alloy - the first being an “Onboarding” workflow, which does traditional KYC and fraud checks, and a second “Underwriting” workflow which does a credit pull and runs through your credit policy to assign a credit limit and APR.

An Application is stateful, meaning your customer’s application can be in only one “step” (or “node”) of the application at a given time and is advanced based on the configured outcomes (or “edges”) of your workflows or manual application review.

Applications will help simplify your use of Alloy and can be the agent of record of what state each of your end-users is in.

Journey Application State: A representation of the current conglomerate state of the group of entities applying together and traveling through the logic of the configured journey, based upon the current state of each individual entity in the group.

Entity Application: A token assigned to a unique combination of an entity and a specific application. Since entities can be part of multiple applications, and applications can contain multiple entities, we assign a unique token to this combination.

Workflow Nodes: These nodes include your policy logic in the form of input attributes, data services, tags, output attributes, etc.

Document Verification Nodes: If a customer’s identification documents need to be verified during an application, you can utilize document verification within a Journey.

Action Nodes: There may be times when you want to account for an event that is not directly handled by the Alloy system, such as extending an offer to a customer or making a request to an external service. Action nodes can be used for this purpose.

Branches: Branches generally represent different pathways for different types of Entities that you would like to run through your Journey which could allow for different Outcomes. For instance, you may have a “Persons” Branch and a “Businesses” Branch, each Branch would have its own way of reaching an Approved or Denied Outcome. Branches also allow for different pathways to Reconciliation based on Outcomes.

Reconciliation Logic: This logic is only required for joint or business applications (although it will also work for single-entity applications). It is the high-level logic that determines the outcome of the application as a whole, based upon the outcomes of each individual entity in that application. We recommend that you add Reconciliation Logic to your journey even if you currently only need to send in single-entity applications, in case you ever need to start sending in applications with multiple entities.