SharePoint site link settings
A SharePoint site link is a reusable library connection for file-upload actions and data feeds. It has one friendly name and separate QA and Production identity, site and folder settings.
Open Library settings, select SharePoint sites, then add or open a site link.
Prepare the application registration
Create a dedicated application registration in the organisation’s identity directory. Give it the narrowest Microsoft Graph application permission that supports the journey. A site-selected permission is preferable to access across every site when the organisation can administer it. File read/write permission is required for upload operations and for the Builder’s end-to-end connection test.
Record the registration owner, tenant, permitted site, credential expiry and dependent services. QA should use a non-live site or an isolated folder with synthetic data.
Configure each environment
| Setting | Purpose |
|---|---|
| Site link name | Friendly name builders select for uploads and feeds. It is maintained on the QA side and shared by both environment configurations. |
| Site domain name | The SharePoint Online host, without a protocol or page path. |
| Site address | Optional site path beneath the domain; leave blank for the default team site. |
| Tenant ID | Directory tenant that owns the site and application registration. |
| Client ID | Identifier of the registered application. |
| Client secret value | Protected credential value. Enter the secret value, not the secret’s metadata ID. |
| Scope | Authentication scope; change only for an approved custom configuration. |
| Folder name | Root folder used for library files instead of the default library-ID folder. |
The client secret is stored separately and is shown as masked after entry. Keep the source value in an approved secret manager and rotate it before expiry.
Save, test and apply
flowchart TD
A[Enter environment settings] --> B[Save and test settings]
B --> C[Authenticate application]
C --> D[Resolve site and drive]
D --> E[Create test folder]
E --> F[Upload test file]
F --> G[Delete test file and folder]
G --> H[Apply to environment]The test deliberately checks more than sign-in. Review each result: application authentication, site details, drive details, folder creation, file upload and cleanup. A failure late in the sequence often indicates insufficient file or site permissions even when authentication succeeded.
Save and test settings does not activate the link. After the whole test succeeds, an administrator can select Apply to QA environment or Apply to Production environment. The page records when and by whom each environment was last updated.
Choose the root folder
By default, files are placed beneath a folder named for the library ID. A custom folder name can align with an approved records structure. Changing it affects new paths; it does not move files already stored in the previous location.
Keep action-generated subfolders predictable and validate user-derived path segments. Do not expose a client secret, access token or internal sharing link to service users.
Test the real journey
After applying QA settings, run the actual upload, list or feed operation from a QA service. Confirm:
- the expected site, drive and folder are used;
- file names and metadata are correct;
- the application cannot reach an unapproved site;
- duplicate and invalid paths fail safely;
- feed refresh or upload retry works as designed;
- no live data is used.
The settings test proves generic create, upload and delete access; it does not prove that a service action builds the correct path or maps the correct spreadsheet.
Rotate or remove the connection
To rotate a secret, update and test QA, apply it, repeat for Production and then revoke the old secret at the identity provider. Do not clear the working value before the replacement has been tested.
Before deleting a site link, find all site-upload, list and feed dependencies. Deleting the Builder link does not delete SharePoint files, revoke the application or remove its permissions.