Application Statuses

Entity Application Status

How the Status of Each Individual Entity in Your Application is Determined

Each entity in your Application is assigned a status at various points in the Journey. The status of the group Application as a whole is determined based upon a “hierarchy” of the individual entity’s statuses in the Application. Consequently, if you have a single-entity Application, the status in the first chart will align to the status of the Group Application (the second chart). However, if you have multiple entities in your Application, you can use the Entity Application status to understand what is happening with each individual entity, but you will need to use the second chart to see which entity status “wins out” as the Group Application status.

When you receive the completed_application webhook event, this indicates that the Application processing is complete and there is a final decision. This is the event that you would use to trigger the account opening process on your backend if the applicant was approved.

Note: Scroll to see the entire table.

Webhook Event Type	Associated Journey Node Type(s) (indicates event happens outside of a Journey node)	`entity_application_status` Field (in objects in array `_embedded.entity_applications` of GET Journey Application Response)	`entity_application_status`Definition	Action Required to Move Application Forward	Suggested Text to Display in a Notification to User
`started_application`	start	`running`	The Application is either (a) transitioning to the next node in the Journey or (b) running an Evaluation currently. This status cannot be coerced by a Sandbox persona at this time.	n/a	n/a
`started_evaluation`	workflow, docV	`running`	See above.	n/a	n/a
`data_request_evaluation`	workflow (one which contains data service that requires data request)	`data_request`	A service that has been hit requires the end user to add at least one additional piece of data (which was not present in original payload to the Workflow) in order to complete the Evaluation.	PUT to this endpoint. Sample payload: `{ "entities": [ { "answers": [{ "question_id": 1, "answer_id": 1 }, { "question_id": 2, "answer_id": 1 }, { "question_id": 3, "answer_id": 1 }, { "question_id": 4, "answer_id": 1 }, { "question_id": 5, "answer_id": 1 }] } ] }`	Please fill out this additional information to complete your application…
`completed_evaluation`	workflow, docV	`running`	See above.	n/a	n/a
`pending_documents`	docV	`pending_documents`	A document verification service requires the document information to be added in order to continue. See the PUT request example here >	PUT to this endpoint. Sample payload: `{"entities": [{"entity_type": "person", "branch_name":"persons", "entity_token":"P-DoCabnYKxjavaMtCKkZe", "document_token_front": "D-3i93lbppVAEQvq6yYX0c", "document_token_back": "D-4r5lbppVAEQvq6yYX0d"}]`	Please upload a document (initialize SDK, or other front end for collecting documents)
`pending_step_up`	step up	`pending_step_up`	(This is an updated version of `pending_documents`). A document verification service requires the document information to be added in order to continue. See the PUT request example here >	PUT to this endpoint. Sample payload: `{"entities": [{"entity_type": "person", "branch_name":"persons", "entity_token":"P-DoCabnYKxjavaMtCKkZe", "document_token_front": "D-3i93lbppVAEQvq6yYX0c", "document_token_back": "D-4r5lbppVAEQvq6yYX0d"}]`	Please upload a document (initialize SDK, or other front end)
`pending_step_up_expired`	step up	`pending_step_up`	See above.	n/a	n/a (potentially: Your Application has expired. We have withdrawn your Application)
`pending_action`	action (external service or user action)	`pending_action`	An action node (service node or end user action node) requires a user action in order to continue running the Application.	PUT to this endpoint. Sample payload: `{"outcome": "approved"}`	Please [take this action] to complete your application….
`completed_action`	action (external service or user action)	`running`	See above.	n/a	n/a
`pending_action_expired`	action (external service or user action)	`running`	See above.	n/a	n/a (potentially: Your Application has expired. We have withdrawn your Application)
`pending_review`	manual review	`waiting_review`	An Entity Application requires a manual review in order to continue evaluating.	Manually Review the Application	Your Application is being reviewed. We’ll get back to you soon!
`completed_review`	manual review	`running`	See above.	n/a	(if review is approved) Manual Review approved….please resume application.
`completed_branch`	terminal outcome	`completed`	This Entity Application has completed evaluating; it has reached a terminal Entity Application outcome (this is not necessarily the same as the Journey Application level outcome in an Application with multiple Entities).	n/a	n/a
`has_finished_sending_additional_entities`	*`do_await_additional_entities` option is initialized and is then closed	n/a		n/a	n/a
`completed_reconciliation`	*entity Application has completed and the reconciliation logic has been processed
`completed_application`	*reconciliation logic has been processed and a Group Application review has been made (if necessary)	`completed`	See above.	GET to this endpoint to retrieve all of the information about your completed Application.	Congratulations! You have been Approved! or, We’re sorry, your Application has been Denied.
`error`	n/a	`error`	An Error has occured in the Application. See error message for details. Re-run the Application to try again after resolving.	n/a	Something went wrong while processing your Application. Please try applying again.

Group Application Status Hierarchy:

How Group Application Status is Derived from Entity Applications

This chart illustrates how Alloy determines the status of the Application as a whole, based on the status of each entity in the Application. The statuses are numbered according to where they fall in a hierarchy - we start at (1) and drop to the next if the first case is not met, and so on.

If at Least One Entity in Your App has `entity_application_status` (See Chart Above) of…	…the `status` Field in (in Top Level of GET Journey Application Response) will be….	…and the `journey_application_status` Field in (in Top Level of GET Journey Application Response - This Dictates What you See in Alloy Dashboard) will be….
(1) `error` (else…)	`error`	`Error`
(2) `expired` (else…)	`expired`	`Expired`
(3) `waiting_review` (else…)	`waiting_review`	`Application Review`
(4) `pending_journey_application_review` (else...)	`pending_journey_application_review`	`Application Review`
(5) `data_request` (else…)	`data_request`	`Pending`
(6) `pending_documents` (else…)	`pending_documents`	`Pending`
(7) `pending_action` (else…)	`pending_action`	`Pending`
(8) `pending_step_up` (else…)	`pending_step_up`	`Pending`
(9) `pending_workflow_service` (else…)	`pending_workflow_service`	`Pending`
(10) `reached_auto_decision_node` (else…)	`reached_auto_decision_node`	`Pending`
(11) `running` (else….)	`running`	`Running`

Additional Possible Group Application Statuses:

Please note that the optional key,do_await_additional_entities, can be included in the payload to the POST to this endpoint and should be used if additional entities are added to the Application at a later date. If this field is sent in with the value of true, Alloy will hold the Application open until has_finished_sending_additional_entities is sent in through the PUT request, as shown in the first row of the chart below.

Event/State which Triggers Status	Entity Application status	Step Required to Move Application Forward	`journey_application_status` (what you see in Alloy dashboard)
`do_await_additional_entities` option is initialized and is still open	`pending_additional_entities`	PUT to this endpoint with the `has_finished_sending_additional_entities` key as `true`.	`Pending`
all entities are complete but none of cases in Reconciliation Logic were hit	`completed`	Manually Review the Application	`Application Review`
all entities are complete and Reconciliation Logic is satisfied	`completed`	n/a	Approved	Denied	`Application Review`