#Integration69 personnes en discutent

Hi Tracy, Web-to-Lead could be an option, but the trick would be getting that information to tie back to a contact, which could be difficult, especially if you have existing contacts who would be filling this information out. One option for this is to spin up a non-authenticated experience cloud site. This can be done without using Experience Cloud licenses, and what you can do is embed a Lightning Flow on that Experience Cloud site. Your contacts can then go to this page, fill out the form, and then you could have the flow update that their contact accordingly. The trick would be getting the form to tie back to the correct contact, which you could do potentially by sending them a link with their contact id in the URL, or having them enter their email address in the form and using that to update the correct contact (Or creating a new contact if a contact with that email isn't found). 

@Roopa Sharma, This is a good area to learn early. Many orgs end up with documents in both systems, and the friction shows up exactly where you listed. Here is how each one tends to play out once a setup is live.  

1. Where the documents live - 
   • SharePoint as the home, with Salesforce records pointing to it. The usual choice when the company already runs on Microsoft 365.
   • Salesforce Files, when volumes are small and only CRM users need the documents. The Files related list is flat, with no folders per record.
2. Ways to connect the two
   • Files Connect (native): lets users browse, search and attach SharePoint files from Salesforce, but it does not create a folder per record.
   • Power Automate: a good fit if your team already builds on the Microsoft side. The trade-off is that the logic lives outside Salesforce, on a premium connector. 
   • AppExchange apps: compare them on four things. Does Flow create a folder when a record is created? Do uploads from the record go straight to SharePoint? Do SharePoint's own permissions still apply? Can you trial it in a sandbox first? 
3. Your questions, in practice - 
   • Folder structure: mirror your data model (Account, then Opportunities, then each opportunity), with the same subfolders on every record. Add the record ID to folder names so a rename never breaks a link. 
   • Metadata: tag files with SharePoint columns such as document type, status and record ID, instead of relying on folder names.
   •  Version control: let SharePoint's version history handle it, and avoid saving copies back into Salesforce. 
   • Security: SharePoint decides who can open a file. Salesforce sharing does not carry over to SharePoint on its own, so plan who updates access when an account changes owner.
   • User experience: users should reach a record's folder from the record page, without searching SharePoint.

If you go the AppExchange route, CloudFiles is one app that works this way with SharePoint. With its flow actions, each record gets a folder when it's created, and files are tagged as they arrive. Users open that folder from the record page, and SharePoint's permissions decide what each person can see. https://appexchange.salesforce.com/appxListingDetail?listingId=a0N4V00000Gh9uFUAR

Disclosure: I work at CloudFiles.

To handle retry logic in Apex for callouts (like retrying 2 failed records up to 3 times), you can use Queueable Apex with the Database.AllowsCallouts interface combined with custom exception handling or tracking failed record IDs. Try the following.

public class IntegrationRetryQueueable implements Queueable, Database.AllowsCallouts {
    private List<Id> recordIds;
    private Integer retryCount;
    public IntegrationRetryQueueable(List<Id> recordIds, Integer retryCount) {
        this.recordIds = recordIds;
        this.retryCount = retryCount;
    }
    public void execute(QueueableContext context) {
        List<Id> failedRecords = new List<Id>();
        for (Id recId : recordIds) {
            try {
                // Perform your external callout logic here for recId
                HttpResponse response = makeCallout(recId);
                if (response.getStatusCode() != 200) {
                    failedRecords.add(recId);
                }
            } catch (Exception e) {
                // Catch connection timeouts or callout exceptions
                failedRecords.add(recId);
            }
        }
        // If there are failures and we haven't hit the 3-attempt limit, chain the job
        if (!failedRecords.isEmpty() && retryCount < 3) {
            if (!Test.isRunningTest()) {
                System.enqueueJob(new IntegrationRetryQueueable(failedRecords, retryCount + 1));
            }
        }
    }
    private HttpResponse makeCallout(Id recId) {
        // Implement your HttpRequest and Http send logic here
        Http h = new Http();
        HttpRequest req = new HttpRequest();
        req.setEndpoint('https://api.yourtargetsystem.com/endpoint');
        req.setMethod('POST');
        // Set body based on recId...
        return h.send(req);
    }
}

 One thing I would add is to treat credential rotation as a dependency-mapping exercise, not just a secret update. If several systems consume the same API credentials, documenting each integration, authentication method, owner, scopes, and last known usage can make future rotations much safer. This is especially important when APIs are being used across multiple workflows. For example, a nonprofit may have a verification service such as the Nonprofit Check Plus API connected to other systems, so keeping track of where credentials are used can prevent an unexpected integration failure after rotation. It’s also worth checking application and middleware logs for recent authentication calls before making the change. That can help identify less obvious consumers that may not be documented in Salesforce or Marketing Cloud. Once the new credentials are deployed, monitoring for authentication failures provides another layer of confirmation that no integration was missed.