*Note: Azure does not allow viewing pictures natively, only downloading. Additionally, making images/recordings available via direct link is not possible by default unless they are made public. Changing this requires configuring workarounds which are discussed in this article.
If you don't know how to set up media endpoints a primer article is available here:
SightCall supports setting up Azure Blob storage as a media endpoint in the admin portal. This article will take you through the general steps to retrieve the access keys to a container to give SightCall access to upload media files into it.
Azure containers/BLOBs (Binary Large Objects = typically images, audio, multimedia objects, etc.) is one of the supported Media Endpoints for pictures and recordings. It is best used as a backup tool for saving media files. It can be paired with another cloud storage option (such as email).
To start the setup: go to your Admin console/tenant (admin.sightcall.com) > Media Endpoints > Add Endpoint > Type: Azure
-
Authentication and container name:
-
- There are two options to authenticate your Azure media endpoint: Access Key and Shared Access Signature (SAS)
- The easiest way is to use Access Key, which provides SightCall access to the specified account and saves media into the specified container.
Find your test container name and your Storage Account name. You can get the access key under your Storage Account Settings - Access Keys in your Azure portal. Make sure to enter it into the SightCall admin portal as displayed in the image above.
Once this is set up, the basic configuration is finished, unless you are using webhooks (only relevant for this storage type if you have a SightCall Integration package). [For Webhooks see point 2.]
-
- The second option to grant Azure account access to SightCall is using Shared Access Signature, in which case it’s possible to provide limited access to the Azure account by specifying exactly what the SightCall application can access. This requires a more complex setup: https://docs.microsoft.com/en-us/azure/storage/blobs/sas-service-create?tabs=dotnet
- In systems like Salesforce, Webhooks can be configured, which means that SightCall will push a message out (called Task in SFDC), on the record containing specific information. This way you can push direct links to files in Azure into the relevant integrated environment, for example: Case records into Salesforce.
Enabling direct links to files in Azure (necessary step)
By now the setup of the media endpoint is complete. Yet by default, links to files in Azure containers do not work and a valid link will lead to a page “The specified resource does not exist.” This is because the default access level is set to Private. This means only the container owner can access the content with an authorized access token. Here are two options how to work around this issue (please choose one):
- Make the container/blob Public. This can be a source of data privacy breaches because anyone with a valid link would be able to access it. This is the easiest and simplest way to work around the above mentioned error. Here are the steps:
- To grant anonymous users read access to a container and its blobs, you have multiple options when choosing the container public access levels. When you grant public access to a container, anonymous users can read blobs within a publicly accessible container without having to authorize the request
- Log in to the Azure portal and then go to the container; click on the 3 dots (…) and then click on Change access level
By default 3 access levels will be presented:
- No public read access: The container and its blobs can be accessed only by the storage account owner. This is the default for all new containers.
- Public read access for blobs only: Blobs within the container can be read by anonymous request, but container data is not available. Anonymous clients cannot enumerate the blobs within the container.
- Public read access for container and its blobs: All container and blob data can be read by anonymous request. Clients can enumerate blobs within the container by anonymous request, but cannot enumerate containers within the storage account.
- Select Blob (anonymous read access for blobs only) The error should not show anymore when users who are not the owner access the blob storage container
-
Setting up an Azure function that would act as an authentication check, making sure that the user that is logged in has access to the file. This is pretty complex and requires some further configuration that needs to be done on the customer’s end (SightCall is not responsible for the setup of this step). Documentation for this (among others):
Folder Structure
It’s also possible to create a folder structure via the Picture directory from the SightCall admin portal for pictures and recordings saved in Azure.
Several options are available here:
-
Add the name of an existing folder
-
Create a folder with predefined letters
-
Create a folder with a variable
The only thing you need to add at the beginning of the picture name is the following:
./
./myfoldername
./${reference}
You can modify these in the admin portal under: Usecase > Picture Settings. Quick Access buttons are available below the Picture Name field to choose which data points will be part of the name.
Here is an example, where a folder will be created, the folder name is the "reference" and the picture name is "reference, time, date and picture number" .
The pictures name has the following variables "${reference}-${time}-${date}-${number}"
To summarize, the name of the picture has 2 parts as shown below:
./myfoldername/mypicturename
Remember, the folder name creation is initiated with ./ The name of the folder and the name of the picture are separated by a "/"