Events

Events let one piece of logic announce that something happened, such as “order placed” or “case escalated”, without knowing who reacts to it. An event definition describes the event and the values it carries. A logic flow publishes the event, and any number of event handlers react to it by running their own logic flows. You can add, change or remove handlers without touching the flow that publishes the event.

flowchart LR
  A[Logic flow<br/>Publish Event] --> E((Event))
  E --> H1[Event handler<br/>sync]
  E --> H2[Event handler<br/>async]
  H1 --> F1[Logic flow]
  H2 --> F2[Logic flow]

All three live in the Events group of the app: Logic FabricEvents holds Event Definitions, Event Handlers and Events (the events that were published).

Define an event

1. Go to Logic FabricEventsEvent Definitions and select New.
2. Enter a Name and choose the Project. Both are locked after the first save.
3. In Properties, beside General and Docs, add a property. The Add Property panel asks for:
   • Name: must be unique within the event (“Name is already taken” otherwise).
   • Type: choose a type from the type picker.
   • List of values: switch on when the property holds several values.
   • Is Required: switch on when every published event must provide a value.
4. Repeat for each property, then save the form.

Property types

The type picker offers the same types as logic block and logic flow inputs:

Type	Notes
Yes/No	On-premises: Two Options
Date and Time	Also asks for the DateTime Behavior: Date Only, Time Zone Independent or User Local
Decimal Number, Floating Point Number, Whole Number
Currency
Text
Row	On-premises: Entity. Choose the table, then at least one column.
Lookup	Choose the table
Choice	On-premises: Option Set. Choose a local choice of a table, or a global choice.

List properties

Once a type is complete, the List of values switch appears under it, with a line that says what the property holds, such as “Holds a list of Contact rows” or “Holds one lookup to Account”. The properties grid shows a list property’s type as “List of Text”, “List of Lookup”, and so on. Use a list when one event carries several items, for example all the order lines of an order.

Handle an event

An event handler runs one logic flow whenever its event is published.

1. Go to Logic FabricEventsEvent Handlers and select New.
2. Enter a Name and choose the Project.
3. Choose the Event Definition to react to and the Logic Flow to run. Both are locked after the first save.
4. Set Async to No to run the flow when the event is published, as part of that operation, or Yes to run it in the background.
5. In Logic Flow Input, beside General and Docs, enter an expression for each input of the flow. Usually you pass an event property straight through, for example the event’s OrderId to the flow’s OrderId input.
6. Save the form.

The handler cannot be saved until every required flow input has a value (“Logic Flow contains one or more required properties.”).

Publish an event

• From a logic flow: add the Publish Event step, choose the Event Definition and set its Properties. Required properties must be set. See message steps.
• By hand: go to Logic FabricEventsEvents, select New, choose an event definition, set the property values and save. List properties are edited one value per row. This is useful for testing your handlers.

Each publish creates an Event record that holds the values it was published with.

How it behaves

• Handlers with Async set to No run when the event is published, as part of the operation that published it. Handlers with Async set to Yes run in the background.
• The order in which handlers of the same event run is not defined. Do not design handlers that depend on each other’s results; if steps must happen in sequence, put them in one flow.
• If a handler with Async set to No fails or ends with Raise Error, the Publish Event step fails and handlers that have not run yet do not run. When the publishing flow runs inside a record operation (a recipe’s Validation, Before or synchronous After stage, or another synchronous handler), the whole operation is rolled back. In the background (a schedule, or an asynchronous recipe stage or handler), a Try / Catch around Publish Event can handle the error.
• An event definition that a logic flow publishes cannot be deleted (“Event definition is in use by a logic flow. Remove all dependencies before deleting.”).
• If some saved input values of a handler cannot be read, the form opens with those inputs empty and says so (“Some saved input values couldn’t be read, so those inputs are empty.”). Set them again before saving.
• In a project whose solution is managed, definitions and handlers open read-only.

Example: order placed

A sales team wants three things to happen when an order is submitted: the customer gets a confirmation email, the warehouse system is informed, and the account’s last-order date is updated.

1. Create the event definition OrderPlaced with the properties Order (Lookup to Order, required), Customer (Lookup to Account, required), Total (Currency) and ProductIds (Text, List of values).
2. In the order submission flow, add a Publish Event step for OrderPlaced.
3. Create three handlers:
   • Update last order date: Async = No, so the account is updated together with the submission.
   • Send order confirmation: Async = Yes.
   • Notify warehouse: Async = Yes. Its flow calls the warehouse API through a service connection.

Later, the marketing team adds a fourth handler for loyalty points, without changing the submission flow.

Related

• Logic flows
• Logic recipes
• Schedules
• Inputs and outputs