If you make a change in an active Form used in an MA Flow, you should be aware that you might affect the operation of the Flow.

This article will describe when this might happen and the steps that you need to take to fix this problem.

Regarding Form Events

Every time a visitor interacts with an active Form, it emits an event. The type of event depends on the kind of interaction. Forms emit three types of events:

  • the View event, which is emitted when a visitor loads the Form is on their browser,

  • the Start event, when a visitor starts filling in the Form, and,

  • the Submit event, when a visitor finally presses the Submit button.

Each Form generates a unique "class" of the Submit event. A hypothetical Form A, for example, will emit a Submit event specific to it; let's call it Submit-FormA. Another hypothetical Form B will emit an event that might be called Submit-FormB.

Internally, the names for these events are a bit more complex but follow the same principle. Each event is identified through their "discriminator", which is the name of the specific event.

Each event contains a set of default attributes. Submit events also include attributes that match the fields of the Form. When a Form emits that event, it populates every attribute with the values of their respective fields in the Form. In our example, if Form A contains Email, First Name and Last Name fields, then the Submit-FormA event will have Email, First Name and Last Name attributes that carry the values that the visitor typed in those fields.

Connecting to MA Flows

When you create an MA Flow, you might use these events and event attributes in nodes. For example, you might listen for a Submit event and even choose to trigger the MA Flow on specific event attribute data, e.g. a particular range of birth dates.

Going back to the example of Form A, when you connect it to an MA Flow, the Flow will specifically expect the "Submit-FormA" event, with the specific event attributes and data in it. When the Flow is active, it will be triggered only by the specific "Submit-FormA" event that carries "Email", "First Name", and "Last Name" attributes (even if they are empty).

Changes to Forms and Versioning

What happens then if you decide to edit a live Form that is connected to an MA Flow? For example, if we were to add a new Phone Number field to Form A?

The change in the Form **will affect the data model** of both the Form and its Submit event. The Form will be emitting a new version of the event to match the changes in its fields. In the example, the event will still be known as Submit-FormA, but internally it will be a new version of it (e.g. 2 instead of 1).

As it may have become apparent, this is not the exact version of the event that the MA flow is expecting.

Our example Flow A might not be triggered by the new version of "Submit-FormA" because it is still set to expect a specific set of fields based on the old version of the event. So, if the changes in the Form model are significant, the MA Flow will still be operational, but the new events will not trigger it.

(Bear in mind that small aesthetic changes, e.g. changing the placeholder text in a field, don't affect the Form events. For that to happen, a Form must be modified substantially, e.g. adding and removing a field or editing the field attribute assignment.)

How to Fix

In this case, you need to be aware that the MA Flow needs to be updated to respond to the changes in the Form events.

You need to stop the Flow, edit the MA node that depends on the Form, and reselect the Event, Activity and Match.

From that point onward, the Flow will work as before.

Did this answer your question?