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 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:
Keeping these separate prevents sales-stage clutter from polluting the active job workspace.
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.
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.
2024-0412 - Polar Bear - White Plains Hospital.Prospect Folder Link, Job Folder Link) so users can navigate directly from the record.When the network drive is managed by an external MSP, expect the following friction points:
[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.