Video browsing - Salesforce security & visibility aspects

Similarly to the first topic discussed in the advanced recording section (link here), we are now going to illustrate the fundamental record visibility assumptions that need to be understood when employing NativeVideo's browsing capabilities. Again, we will consider both scenarios, under one to one and one to many configurations.

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

If you haven't followed the previous sections of this Wiki, please have a read here, this 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.

As you can imagine if you've read through the equivalent section dedicated to the recording, the running user must have at least read access to the target record in order to be able to watch the video referenced by the custom lookup field. Again to fully review this scenario:

Sharing: The running user must have read access to the target record
CRUD: Read access to the object that describes the target record
FLS: Read on the configured lookup field for the video on the target record's object
Video, questionnaire and questions are all read without sharing, so you don't need to worry about it

Fairly simple, let's look at the high level process that NativeVideo follows to render the video. When a VideoList component is rendered, the logic applied is:

Check if the running user has read access to the target record
Fetch the videos and associated questionnaire details, if any
Fetch related information, such as the video owner label
Generate an authentication token from the video platform, based on the video external ID stored on the Video__c record
On the client side, display the video player

Easy, let's move to the equivalent overview for the one to many scenario.

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.

Similarly to the previous section on this page, a set of videos associated to a parent record is made visible if the running user has at least read access to the parent record itself. No further configurations or checks are required, if the user can access the parent record, they can play all videos associated to it via the video junctions. In order to list again all visibility relevant concepts:

Sharing: The running user must have read access to the parent record
CRUD: Read access to the object that describes the parent record and also to the configured junction object
FLS: Read on the configured lookup fields on the junction, both the video and the lookup to the parent object
Video, questionnaire and questions are read without sharing, so again no issues here

If we then describe what happens when you render the VideoList component configured to support a one to many scenario:

Check if the running user has read access on the parent record
Fetch the videos and associated questionnaires information if any. For now the last 100 videos sorted by created date are displayed
Get the associated video information, such as the video owner labels
Generate an authentication token on the video platform, based on the list of video external IDs
On the client side, display a carousel of video players

Conclusion & Next Steps

In this section we have introduced the record visibility requirements and the high level steps followed by NativeVideo to display the recorded videos.

In the next sections we will continue to look at more advanced topics, like how to embed video browsing in your pages.