This guideline is part of a three-step process:
- Connecting Surveypal to Salesfore
- Selecting user profile and root object in Salesforce
- Mapping survey responses to Salesforce
Selecting user profile
In this view you must first select which user profile or profiles integration should use on Salesforce side when it push information to Salesforce objects.
By default there are three profiles
- System Administrator
- Standard User
- Standard Platform User
Surveypal integration will add field AnswerId to Salesforce object which is updated by integration. Integration write also feedback name to object field Name (this is field name) so this field type must be Text. User profile must have rights to read and modify AnswerId field. For example if Standard User and Standard Platform User don't have read and write rights then you can remove these profiles from the list (press minus).
It's enough if there is only one profile which have write access to object what you will update with integration.
Selecting which Salesforce object should be affected by the integration
Next you need to select which kind of object is updated or created on Salesforce side when there's a new response to the survey. The selected object is also called root object in the context of the integration. Only objects that can be at least updated through the integration are shown. Some Salesforce standard objects, e.g. Contacts, can only be updated, but not created through the integration. If you can't see your object in the list, check the object settings and make sure that "Allow search" is selected.
In this example, we're choosing Case as our root object.
Setting up how the correct root object instance is found in Salesforce
After selecting which object to use, you can set up how to find the correct Salesforce object instance. In other words, we're telling the integration which one of the numerous Cases we want to update with the input from a certain survey response.
If an existing instance is found, it is updated. The integration engine might also come to the conclusion that there's no related Case to the survey response given. If an existing instance is not found, a new object is created. A more detailed explanation can be found here.
In the second dropdown, we choose which of the root object's fields is used to identify the correct instance. In this example, we're trying to find an existing Case by Case ID. Any unique identifier can be used in addition to id fields.
Now that the Salesforce object's identifying field is selected, we must choose where the value for the identifier comes from. The most common case is to get the identifier from response metadata. This is done by choosing the option "Recipient background information: ...", in our case "Recipient background information: sf_case". Adding metadata to survey responses is explained in the next phase.
You can also get the identifier directly from the input to one of the survey questions. We don't recommend to use this with error prone identifiers like Salesforce object ids. It's very easy to make a typo when writing something like that in an open field. On the other hand, email addresses written by respondents could easily be used as identifying information.
This phase is now ready and "Next" can be clicked to proceed to mappings.