3. Configure
Before using Filenize, follow the steps below to enable Salesforce to connect to SharePoint and SharePoint to provide access to Salesforce using Azure:
Filenize v3.0 or above offers step-by-step guidance for configuring authentication on the setup screen and validates the setup for its correctness. Install the latest version here.
Creating App Registration in Azure
Navigate to Azure (Microsoft Azure) and select "Azure Active Directory" on the home page to access your company's directory.
On the left-hand side, click on "App Registrations" (https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps).
Click on "New registration" at the top, which opens a new window.
Fill in the required details and select "Web" under "Redirect URI (Optional)". Leave the URL field blank for now; we will fill it in later.
App Client Id and Client Secret
With the app successfully created, follow the steps below to obtain and save the required details:
On the overview page of the app, note down the value listed under "Application (client) ID."
Next, locate the client's secret on the "Certificates & secrets" page.
Create a new client secret on this page. It will prompt you to provide a description and set an expiration for the secret.
After creating the new client secret, it will be displayed, and you should note down the value under the "Value" column. Please save this value immediately since it will be obscured after the page refreshes.
Make sure you have the Application (client) ID and the secret value securely stored somewhere for later use in the configuration process with Filenize.
API Permissions
It's important to select the necessary permissions for the app, and this can be done in the left-hand side menu on the "API Permissions" page. The SharePoint API requires specific permissions to function properly. Follow the steps below to add the required permissions:
On the "API Permissions" page, select "Add a permission." This will display a sidebar on the right where you can choose different apps and their permissions.
Ensure the app has the following permissions:
Microsoft Graph:
User.Read (Allows users to sign in to the Azure app)
SharePoint (Delegated Permissions):
AllSites.FullControl (FullControl is needed for users to share folders. Adjust this to a lower permission if folder sharing is not required.)
Read/Write Items in all site collections (Used to get site, subsite, and list information from SharePoint, and manage folder access for groups and users)
MyFiles.Write (Used to create/delete folders/files)
Sites.Search.All (Run search queries as a user, and used to query all valid SharePoint Sites in the Managed Package Configuration screen)
Some permissions may require admin consent. To grant admin consent, click on "Grant admin consent for <Your Company>." You may be prompted to fill in the password if required.
Make sure to apply the necessary permissions and obtain admin consent where needed to ensure proper functioning of the app with SharePoint.
You are not giving all end-users FullControl
“Delegated permissions are used in the delegated access scenario. They're permissions that allow the application to act on a user's behalf. The application will never be able to access anything the signed in user themselves couldn't access.
For example, imagine an application that has been granted the Files.Read.All delegated permission on behalf of Tom, the user. The application will only be able to read files that Tom can personally access.” (Microsoft Overview of permissions and consent in the Microsoft identity platform - Microsoft identity platform )
This means that Filenize can only share folders if an end-user has Full Control in both SharePoint and Azure. If the user has only Read-only permissions in SharePoint but Full Control in Azure, they will not be able to share folders.
API Permissions are not reflected in Salesforce
Changes in Azure API permissions can take some time to propagate and be processed. The updates may take up to an hour to reflect the changes. If the changes are not visible even after an extended period, re-authentication can be attempted, as it might help resolve the issue. However, it's important to note that the delay in propagating permissions can make debugging challenging. To avoid such difficulties, ensure that Azure is correctly set up from the beginning.
Creating the Auth. Provider in Salesforce
With the Client Id and Client Secret created earlier, we can now create an Auth Provider in Salesforce. To do this, follow these steps:
Go to Filenize’s configuration screen (Tab SharePoint).
Click on “Auth. Providers” button in the “Authentication” section, or go to Auth. Providers in Salesforce Setup.
Click on "New" to create a new Auth Provider.
Select "Open ID Connect" for the Provider Type.
Fill in the following fields:
Name: The name of the Auth Provider (suggestion: SharePoint)
URL Suffix: Same as the Name (automatically filled in)
Consumer Key: This is the Client Id from the Azure app
Consumer Secret: This is the Client Secret from the Azure app
Authorize Endpoint URL: https://login.microsoftonline.com/common/oauth2/authorize?resource=https://YOURTENANTNAME.sharepoint.com/&prompt=login
(Note: Resource needs to reference your SharePoint URL, i.e., https://YOURTENANTNAME.sharepoint.com, and the Prompt needs to have the value "login.")
Token Endpoint URL: https://login.microsoftonline.com/common/oauth2/token
Send Access token in header: Checked
Click on "Save" when you are done to return to the detail page.
Return to the Filenize configuration screen and select your new Auth. Provider in the section “Authentication”.
Make sure the authorization url and token endpoint url are correctly configured. This will ensure all checks are green.
Copy the presented Callback URL, and click on the “Authentication” button to quickly go to the Authentication page in Azure.
Updating the Azure app Callback URL
Go back to Azure or click the “Authentication” button in Filenize’s configuration screen. Use the generated callback URL for your Azure app. You can find this in your app overview under the left-hand side menu page "Authentication." If no platform is selected yet, choose "Web" and then add the Callback URL to this page. After adding the Callback URL, remember to save the page to complete your changes
Creating the Standard User Named Credential
Due to new limitations imposed by Salesforce, we are unable to access internal named credentials within managed packages. Filenize now provides the option to create the named credential for you, ensuring compliance with the new Salesforce requirements. We will phase out support for legacy named credentials, and once this transition is complete, we will update the UI accordingly.
Filenize enables you to quickly generate Named Credentials, External Credentials, and Principle Access rules for standard user, service user, and portal user roles. To do so, navigate to the Filenize configuration screen, go to each role's section, and click the blue "Create Named Credential" button. Once the new named credential is created, it will be automatically selected.
Allow Callouts
Enable Filenize to use the new Named Credential. This is a task that an actual user must perform. Click the "Named Credential" button, edit, and ensure that "Enabled for Callouts" is enabled.
External Credential Principle Access
After creating the Named Credential through Filenize's configuration screen, ensure that you add External Credential Principle Access to the user's profile or a new dedicated permission set. This can be changed by navigating to Salesforce Setup and managing either Profile or Permission Set.
User External Credentials
If not already or configured by default, make sure to provide Read access to the object User External Credentials for your Profile or Permission Set. This permission is needed for standard or portal users to use the created Named Credentials related to the External Credentials.
If your users are not granted the required permissions, Filenize will not be able to connect with SharePoint and may display the following error message:
This concludes the Named Credential setup.
Creating the Service User Named Credential (Optional)
With the Service User you’re allowing end-users access to view SharePoint data that they might not be able to access in SharePoint Online under their own accounts. End-users would be able to view, create, edit, delete folders and files, or perform other actions, effectively bypassing SharePoint's own permission model. This could potentially lead to exposure of sensitive data. Therefore, We strongly recommend to start designing your SharePoint sharing model first, and only allow certain features that are missing for end-users.
With Filenize, it's possible to perform certain features as another user instead of the logged-in user. This capability allows some users to have more control, especially if their own user's permissions are limited.
Follow the same instructions as the previous chapter to create the Service User Named Credential, External Credential, and Princple Access.
The distinction between the Standard User and Service User lies in the authentication process. Every Salesforce user is required to authenticate with the Standard User Named Credential. In contrast, only one Salesforce user, typically the user with SharePoint admin rights, needs to authenticate with the Service User.
After authentication, you can map certain Filenize features to either the Standard User role or the Service User role. Typically, the "Share Folders" feature is assigned to the Service User role, as it necessitates Full Control access for folder sharing.
Done!
With the Authentication Provider, External Credential, and the Named Credential created, only two steps remain for the integration to work:
Let end-users connect to SharePoint using the Named Credential.
Let Filenize know which Named Credential to use.
We will cover these steps in the upcoming chapters.