Many systems that use Flow Results to capture the results of a flow run also maintain a database of contacts:
Contact Properties: Contacts often have custom-defined or system-defined properties (e.g. gender, birthdate, name, etc.) that are persisted to the contact, rather than simply stored as a one-time response to a question.
Group Membership: Contact databases often have the capability to sort contacts into groups.
When Flow Results are used to synchronize the results of a flow run from System B back to System A that manages a contact database, we need a solution to convey contact/group changes back to System A.
(This also updates Flow Results with capabilities introduced in the Flow Specification for blocks that set contact properties or group membership)
Proposal
Introduce optional field on the Question definition to indicate that the response to the Question represents a contact property change:
"ae54d3":{
"type":"multiple_choice",
"label":"Are you male or female?",
"type_options":{
"choices":[
"male",
"female",
"not identified"
]
},
"set_contact_property": "gender"
}
Optional field set_contact_property (string): : If present and set, indicates that a response to this question persists a contact property with the name given in the string. The string represents a property key, which could be a property name, ID, or other definition as relevant between systems. The Question type can be any one of the existing Question types.
Introduce optional field on the Question definition to indicate that the response to the Question represents the updated membership of the contact in a group:
"ae54d3":{
"type":"multiple_choice",
"label":"Are you a farmer?",
"type_options":{
"choices":[
"true",
"false"
]
},
"set_group_membership": "farmers"
}
Optional field set_group_membership (string): : If present and set, indicates that a response to the question represents the updated membership of the contact in a group. The question type must be a compatible type that can be parsed as a boolean (select_one, numeric, or open). The convention is that truthy response values will add the contact to the specified group, falsy response values will remove the contact from the group, and null values will not alter the group membership.
Alternatives
An alternative to this proposal would be the introduction of new Question data types. (A "Contact Property Question" or "Group Membership Question"). However, this would lose the current structure where Question types are based around data types, and should have understandable meaning for all systems that might consume results -- even if they don't manage a contact database. By using an attribute on Questions, we retain the ability to specify data types in the kind of response, while additionally indicating that a contact database operation should be applied.
Background
Many systems that use Flow Results to capture the results of a flow run also maintain a database of contacts:
Contact Properties: Contacts often have custom-defined or system-defined properties (e.g. gender, birthdate, name, etc.) that are persisted to the contact, rather than simply stored as a one-time response to a question.
Group Membership: Contact databases often have the capability to sort contacts into groups.
When Flow Results are used to synchronize the results of a flow run from System B back to System A that manages a contact database, we need a solution to convey contact/group changes back to System A.
(This also updates Flow Results with capabilities introduced in the Flow Specification for blocks that set contact properties or group membership)
Proposal
Optional field: If present and set, indicates that a response to this question persists a contact property with the name given in the string. The string represents a property key, which could be a property name, ID, or other definition as relevant between systems. The Question type can be any one of the existing Question types.
set_contact_property(string):Optional field: If present and set, indicates that a response to the question represents the updated membership of the contact in a group. The question type must be a compatible type that can be parsed as a boolean (select_one, numeric, or open). The convention is that truthy response values will add the contact to the specified group, falsy response values will remove the contact from the group, and null values will not alter the group membership.
set_group_membership(string):Alternatives
An alternative to this proposal would be the introduction of new Question data types. (A "Contact Property Question" or "Group Membership Question"). However, this would lose the current structure where Question types are based around data types, and should have understandable meaning for all systems that might consume results -- even if they don't manage a contact database. By using an attribute on Questions, we retain the ability to specify data types in the kind of response, while additionally indicating that a contact database operation should be applied.