SharePoint Folder Automation from Salesforce

Automating folder creation on a network drive or SharePoint instance from Salesforce triggers is a recurring integration challenge, particularly when the file storage is managed by a third-party MSP with strict security controls. Two primary architectural approaches exist depending on what the MSP will permit.

The Core Pattern

The goal is to trigger folder creation on a network drive at a defined point in a Salesforce workflow — typically when a record reaches a certain stage (e.g., Lead converted to Opportunity, or Opportunity marked Closed Won). The folder name is usually derived from a record field such as a prospect number or job number, ensuring a consistent naming convention across both systems.

In practice this often involves a two-step folder lifecycle:

Prospect/Sales folder — created when an Opportunity is opened (or a Lead is converted), used to collect drawings, specs, and correspondence during the sales process.
Job folder — created when the Opportunity is won and a contract is signed, containing only the relevant subset of files needed for production/delivery.

Keeping these separate prevents sales-stage clutter from polluting the active job workspace.

Approach 1: API-Based Integration

If the MSP or storage provider can issue a long-lived shared API key for the network share or SharePoint tenant, Salesforce can call out directly using a Flow or Apex trigger.

How it works:
- A Salesforce record change (e.g., Opportunity stage update) fires a trigger.
- An outbound HTTP callout sends a request to the storage API with the folder name and target path.
- The storage system creates the folder and optionally returns a link that can be written back to the Salesforce record (e.g., a "Folder Link" field on the Opportunity).

Requirements:
- MSP must provide API credentials and document the endpoint.
- Named Credential or custom metadata in Salesforce stores the key securely.
- The MSP's security policy must permit inbound API calls from Salesforce IP ranges.

Tradeoff: Cleanest solution with no on-premise footprint, but requires MSP cooperation and may conflict with strict security postures.

Approach 2: Local App Container (On-Premise Listener)

When the MSP will not expose an external API — common in tightly controlled environments where even installing software requires a ticket — a small on-premise application can act as a bridge.

How it works:
- A lightweight app (Windows service, Linux container, or small VM) runs inside the client's network where it already has native access to the mapped drive.
- The app polls Salesforce (via the REST API or Platform Events) for new records or stage changes.
- On detecting a trigger condition, it creates the folder locally using the drive path it already has access to.
- Optionally writes the resulting folder path back to Salesforce.

Requirements:
- A machine or VM inside the office network with persistent uptime.
- Salesforce Connected App credentials for the polling service.
- Drive access already provisioned for the machine (no new MSP permissions needed for the drive itself).

Tradeoff: Avoids MSP API negotiation entirely, but introduces an on-premise dependency that must be maintained.

Key Implementation Details

Folder naming: Use the Salesforce-generated prospect or job number as the primary folder name component to ensure uniqueness and cross-system traceability. Example: 2024-0412 - Polar Bear - White Plains Hospital.
Template copying: Many clients maintain a template folder with a standard subfolder structure. Automation should copy this template rather than create a blank folder, preserving the expected file organization.
Folder link writeback: After creation, store the resulting folder URL or UNC path in a Salesforce field (e.g., Prospect Folder Link, Job Folder Link) so users can navigate directly from the record.
Two-folder lifecycle: Implement separate triggers for the prospect folder (on Opportunity creation or Lead conversion) and the job folder (on Closed Won), and avoid automatically migrating all files — only copy the relevant subset.

MSP Coordination

When the network drive is managed by an external MSP, expect the following friction points:

Security review: MSPs with strict postures (common in SMB environments) may require formal approval before exposing any API surface or allowing inbound connections.
Billing: Any MSP involvement typically incurs hourly charges; client authorization (usually from a decision-maker, not the day-to-day contact) is required before engaging.
Point of contact: Identify the specific MSP engineer assigned to the account rather than going through the general helpdesk ticket queue, which slows technical discussions significantly.
Preferred path: Request an introduction via email directly to the MSP technical contact so the development team can handle the technical conversation without routing through the client each time.

Client Example

^[1] uses this pattern with an iDrive network share managed by Veith Consulting (a local MSP). Their Salesforce instance generates a prospect number on the Opportunity record; the goal is to automate creation of a prospect folder in the Sales directory and a job folder in the Jobs directory upon Closed Won. The MSP's security controls require coordination before either API approach can be confirmed. See ^[2] for full context.

^[3]
^[1]
^[4]