Event Status & Lifecycles
Ongoing account activity often moves through several statuses before it's complete, and you may want to monitor it at more than one of them. For example, you might monitor a login event when the login is attempted, and again when it succeeds or fails. You might also send a transaction to Alloy when it's first acknowledged, then send it again once it's completed to reconcile the data.
Alloy's Event Status and Event Lifecycle features let you track each of these stages and control what monitoring Alloy runs, if any, at each one.
Event Status
The event_status field is an optional field on your event request that tells Alloy where the event is in its lifecycle. Each event type comes with a set of default status values, and you can add your own custom statuses for your use case.
Event Status vs. other status fieldsSome Event Types, including
transactionandlogin, have their ownstatusfield in their schema. This field is not the same asevent_status, so you need to map it separately, even if you plan to send the same value in both fields.If you leave out
event_statusbut include status on atransactionorloginEvent, Alloy uses thestatusvalue as the Event Status.
Control Entity Data Storage with Event Status
In addition to mapping Workflows at the status level, you can control whether Alloy saves an event's data to the Entity profile. This is most helpful in flows where you might reject the data submitted in an event. In that case, you can keep Alloy from saving the rejected data, which keeps the Entity profile in sync across your systems.
Event Lifecycle ID
The event_lifecycle_id field is another optional field that ties sub-events with different event_status values to one unified event record, so you can build end-to-end monitoring flows across statuses in the same Ongoing Journey.
For transaction and login events, Alloy recommends sending the same value in event_lifecycle_id that you send in external_transaction_id or external_login_id, and treating the two IDs as equivalent.
Updated 3 days ago