Technical
Required structure¶
This is the standard structure that the integration expects and needs to function properly, however every table and field name can be configured in the lime-admin config.
Related limetype is a placeholder name for the limetype you want participant to have a relation to (person or company is often used). Read more here.
Marketing activity(Campaign)¶
| Field name | Required | Field type | Description |
|---|---|---|---|
| name | x | Text field | Name of the marketing activity |
| type | Option list | Used to filter out the kind of campaigns to see in Lime Marketing | |
| campaignstatus | Option list | Used to filter out the status of campaign to see in Lime Marketing | |
| participant | x | Relation(1:n campaign-participant) | The participants that will be in the marketing activity |
Related limetype(Person, Company or other)¶
| Field name | Required | Field type | Description |
|---|---|---|---|
| x | Link field | Email to the related limetype IMPORTANT | |
| participant | x | Relation(1:n related-participant) | Relation to participant, a related limetype can have many participants |
Participant¶
| Field name | Required | Field type | Description |
|---|---|---|---|
| related limetype | x | Relation(1:n related-participant) | Relation to chosen limetype (ex. person or company) |
| campaign | x | Relation(1:n campaign-participant) | Relation to campaign |
| participantstatus | x | Option list | Status for the participant |
| formresponse | x | Text field | Holds the formresponses for participant (default uses misc field) |
| formresponseid | x | Integer | Id of the formresponse (can be hidden) |
Participantstatus¶
These statuses are used by the integration, and therefore must exist as keys on the participantstatus option field:
| Key |
|---|
| accept |
| decline |
| invitation |
| queue |
| participated |
Description of the participant logic¶
When a participant is updated/created we try to find a participant id by: form response id, person id or unique email address.
It starts by checking if the request contains a form response id and tries to match it to an existing participant, new responses will not have a form response id.
Next it tries to find a person id in the request payload under the ExternalPersonId property (this will not be present for custom webhook listeners). For this to work the email address must match the person id.
The last fallback is if the form response email is unique for the campaign, it will then attach the form response to the already existing participant matching the email.
If no existing participant can be found a new ad-hoc participant will be created. It will be connected to a limetype of your choosing (person, company etc. more info) that has a email property if the form response email is unique in the system, otherwise the participant will be unconnected.
A message will be published to the lime-event message-queue for all ad-hoc participants that are not connected. It is then possible to create a custom event handler that will either create a new (for example) person or to match it to an existing person.