Video recording - Salesforce security & visibility aspects

In this section we will discuss the visibility assumptions that you need to be aware of for both video recording scenarios, so either when you record a video attached to a specific Salesforce record, or when you record multiple videos for a given parent record. Let's take a look at both options.

1. Visibility assumptions for the One-to-One scenario

If you haven't followed the previous sections of this Wiki, please have a read of this section here, that introduces you to the concept of One-to-One scenario, effectively offering the option to save a video as a custom lookup field on any given Salesforce object.

Fundamentally, a running user who wants to record a video under this scenario needs to have both read and write access to the target record, in other words the running user needs to be able to see and edit the record where the video lookup is hosted. Fair and simple point, no? Just to be a bit more formal:

• Sharing: The running user needs to have read and write access to the target record
• CRUD: The profile / permission sets applied to the running user must enable read and write access to the object defining the target record
• FLS: Read & Edit on the configured video lookup field on the target object
• Questionnaire and questions are read without sharing, so you don't need to worry about them in case you are running video interviews

Let's also take a closer look on the process that gets activated during the video recording bootstrap:

1. At first, some authorisation checks are run for you:
   
   1. Verify if the running user has Read & Write access to the target record
   2. If the running user's profile is Guest (Un-authenticated community user), check the provided token against the token field (there is a dedicated section for this, don't worry)
2. Load the questionnaire data, if any:
   1. If a questionnaire ID is specified, return that specific one
   2. If a lookup field is referenced, load it from that field
   3. If none, check if there are questionnaires defined for the target object API name
3. Generate an authentication token with the video platform, so that we can unlock the permissions required to run the recording of a new video
4. On the client side, pick the questionnaire, if more than one are available
5. Record the video, either as interview and answering the questions of the questionnaire, or as a freestyle video
6. Update the target record on the configured lookup field, with a reference of the new video record. Clone the questions that have been asked, if any.

That's it.

2. Visibility assumptions for the Many-to-One scenario

In this paragraph we cover the scenario in which we are not uploading a single video per record, but instead we create a gallery of videos for each given record. If you haven't read how we can offer that, please take some time to review the dedicated section here.

Again, the fundamental assumption in regards to record visibility and multiple video recording is that a running user must have read access to the parent record. In other words, in order to record multiple videos against a specific record, the running user must have read access to that record. Again, pretty straightforward.
Looking from all possible angles:

• Sharing: The running user must have read access to the parent record, the one referenced by all videos
• CRUD: Again read access to the object of the parent record, plus write access on the configured junction object. If the out of the box Video_Junction__c object is used, the NativeVideo permission set will cover the second part of this requirement
• FLS: Edit on the video lookups defined on the configured junction object, so both on the video and parent object lookups
• Questionnaire and questions are read without sharing, as per the previous scenario

Finally, let's take a closer look at the high level process triggered to guarantee that the right level of security is in place:

1. Verify if the running user has read access on the parent record. Block the user otherwise.
2. Load the questionnaire, if any:
   1. If a questionnaire ID is specified, return that specific one
   2. If a lookup field is referenced, load it from that field
   3. If none, check if there are questionnaires for the target object API name
3. Generate an authtication token, so that the recording of a new video is granted
4. On the client side, pick the questionnaire, if more than one are available
5. Record the video, as an interview, answering the questions of the questionnaire or as a simple recording
6. Create a new record of the configured junction object, linking the new video record with the configured parent record. Clone the questions that have been asked, if any.

Conclusion & Next Steps

We have discussed which are the fundamental assumptions in regard to record visibility and overall how NativeVideo works from an high level point of view, both if one single video or multiple videos are recorded.

In the next sections we will continue to look at more advanced topics, like how to embed video recordings in your pages. If you are instead looking for information on the video browsing functionality, look here.