Documentation Index
Fetch the complete documentation index at: https://docs.digifist.com/llms.txt
Use this file to discover all available pages before exploring further.
Domain events are the internal communication layer between Galantis’s webhook handlers and the rest of the application. When a Shopify webhook is received and processed by a handler job, the job fires one or more domain events. Other parts of the system — automation triggers, segment re-evaluation, real-time broadcasting — subscribe to these events and react accordingly.
This decoupled architecture means webhook handlers do not need to know about automation logic, and automation logic does not need to know about webhook format. Each layer communicates through typed events with well-defined payloads.
What this covers
- Shopify-triggered domain events and what fires them
- Automation trigger events and how they map to domain events
- Broadcast events for real-time dashboard updates
- How listeners subscribe to events
Shopify-triggered domain events
These events are fired by Shopify webhook handler jobs after processing the incoming payload. Each event carries the relevant entity data needed by downstream listeners.
Customer events
| Event | Fired by | Payload |
|---|
CustomerCreated | ProcessShopifyCustomerCreatedJob | New customer record data |
CustomerUpdated | ProcessShopifyCustomerUpdatedJob | Updated customer record with changed fields |
CustomerDeleted | ProcessShopifyCustomerDeletedJob | Customer ID |
CustomerMarketingConsentUpdated | ProcessShopifyCustomerMarketingConsentUpdatedJob | Customer ID and new marketing_state |
CustomerTagsAdded | ProcessShopifyCustomerTagsAddedJob | Customer ID and array of added tags |
CustomerTagsRemoved | ProcessShopifyCustomerTagsRemovedJob | Customer ID and array of removed tags |
CustomerCreated → Automation trigger evaluation for CUSTOMER_CREATED
CustomerUpdated → Segment rule re-evaluation for the updated customer; marketing_state propagation if consent changed
CustomerMarketingConsentUpdated → marketing_state update on the contact record; re-evaluation of any pending automation enrollments
CustomerTagsAdded → Automation trigger evaluation for CUSTOMER_TAGGED (if a specific watched tag was added); segment rule re-evaluation for tag-based rules
Order events
| Event | Fired by | Payload |
|---|
OrderCreated | ProcessShopifyOrderCreatedJob | Full order data including line items, customer reference, and totals |
OrderCancelled | ProcessShopifyOrderCancelledJob | Order data with cancellation reason |
OrderShipped | ProcessShopifyOrderShippedJob | Order data with fulfillment details including tracking information |
OrderCreated → Automation trigger evaluation for ORDER_PLACED; customer purchase history update for segment re-evaluation
OrderCancelled → Automation trigger evaluation for ORDER_CANCELLED
OrderShipped → Automation trigger evaluation for ORDER_SHIPPED
Product events
| Event | Fired by | Payload |
|---|
ProductCreated | ProcessShopifyProductCreatedJob | Full product data including variants |
ProductUpdated | ProcessShopifyProductUpdatedJob | Updated product data; includes inventory change data for Back-in-Stock detection |
ProductDeleted | ProcessShopifyProductDeletedJob | Product ID |
CollectionUpdated | ProcessShopifyCollectionUpdatedJob | Collection data with product membership changes |
ProductUpdated → Back-in-Stock restock detection (inventory 0→>0 check); Meta catalog sync queue (SyncMetaCatalogJob); segment re-evaluation for collection/product-based rules
CollectionUpdated → Segment rule re-evaluation for Purchased collection conditions
Automation trigger events
Automation trigger events are a distinct layer above the Shopify domain events. They represent the business-level trigger conditions that automations subscribe to, rather than the raw Shopify data changes.
Some automation triggers map directly to a single domain event. Others require evaluation logic before the trigger event fires.
| Automation trigger event | Source | Trigger condition |
|---|
UserAddedToListTrigger | Galantis list management | Customer manually or programmatically added to a specific list |
UserAddedToSegmentTrigger | Segment evaluation | Customer newly matches a segment’s rules (membership transition) |
AbandonedCheckoutTrigger | Polling job | Incomplete checkout detected for a customer via 10-minute poll |
BackInStockTrigger | ProductUpdated event | inventory_quantity changed from 0 to >0 on a variant with active subscribers |
ORDER_PLACED, ORDER_CANCELLED, ORDER_SHIPPED, CUSTOMER_CREATED, CUSTOMER_TAGGED — map directly to their corresponding Shopify domain events (OrderCreated, OrderCancelled, OrderShipped, CustomerCreated, CustomerTagsAdded). The automation engine listens to these domain events and evaluates trigger conditions for any active automations using those trigger types.
Trigger event processing
When an automation trigger event fires for a customer:
- The automation engine identifies all active automations with a matching trigger type
- For each matching automation, eligibility checks run:
- Consent check:
marketing_state = SUBSCRIBED?
- Frequency cap check: within the configured cap window?
- Exclusion rule check: member of any excluded list or segment?
- Eligible customers are enrolled — a new
AutomationActivity execution context is created
- The first node in the flow executes (Delay, Condition, or Action)
Broadcast events
Broadcast events are real-time events pushed to connected merchant dashboard clients via Laravel Reverb WebSocket connections. They enable live updates in the Inbox without polling.
| Event | Trigger | What it updates |
|---|
ConversationMessageCreated | New inbound message received from Meta webhook | Inbox — new message appears in the conversation thread immediately |
ConversationMessageCreated is fired after:
- The inbound message Meta webhook is received and validated
- A
Conversation and Message record are created
- Laravel Reverb broadcasts the event to the merchant’s active dashboard WebSocket connection
- The Inbox React component receives the broadcast and updates the conversation thread without a page refresh
Event listener architecture
Domain events in Galantis follow Laravel’s event and listener pattern. Events are dispatched synchronously from handler jobs after the primary record operation completes. Listeners are registered in the application’s EventServiceProvider and execute in the order they are registered.
For operations that could be slow — such as triggering segment re-evaluation for a customer whose data just changed — listeners dispatch new queue jobs rather than performing the work synchronously. This keeps event dispatch fast and moves expensive downstream processing to the queue layer.
The event → listener → queue pattern means:
Webhook received
→ Handler job (queue)
→ Record updated
→ Domain event fired (synchronous)
→ Listeners run
→ Fast operations run inline (e.g., flag update on record)
→ Slow operations dispatch queue jobs (e.g., segment re-evaluation, automation trigger)
→ Automation trigger job (queue)
→ Customer eligibility checks
→ Enrollment and first node execution
