#Integration68 discutindo

@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. 

Hi Cloud Crafter, 

Short answer: don't clone the app — generalize it. Build the integration logic once as a reusable, config-driven layer, then add the second API as a new configuration, not a new copy of the app. 

Why cloning is the wrong move: 

- Two copies of the same objects/flows/Apex means every future bug fix, security patch, or workflow change has to be done twice, and they will drift out of sync within months. 

- It roughly doubles your metadata footprint in the same org for no real functional benefit, since both integrations share the same overall structure anyway. 

- It makes testing, permissions, and reporting messier — you'll end up needing to explain to users/admins why there are two near-identical apps doing conceptually the same thing. 

Recommended approach: 

1. Extract what's actually integration-specific into configuration, not code/metadata. Things like endpoint URLs, auth credentials, field mappings, and payload structure should live in Custom Metadata Types or Named Credentials/External Credentials — not hardcoded per-integration Apex classes or per-integration Flows. 

2. Keep one set of core objects, screens, and automations, parameterized by an "Integration Type" or "Source System" field/record, so the same Flow/Apex logic branches or reads config rather than being duplicated. 

3. Use Named Credentials (or External Credentials with Named Principals) per third-party API. This is the standard Salesforce pattern for "same integration pattern, multiple external systems" — one generic Apex HTTP callout class, driven by whichever Named Credential/config record applies. 

4. If the two integrations genuinely have very different data models or business logic (not just a different endpoint), that's the signal to build a second app rather than force everything into one config-driven framework — don't over-engineer for reuse that doesn't fit. 

On sandbox vs. new org: stay in the same org/sandbox unless there's a hard business reason to separate (e.g., different client legal entities, data residency requirements, or genuinely unrelated user bases). A second full org means duplicating users, licenses, security model, and ongoing maintenance — that's a much bigger cost than it sounds, and it's rarely justified just because it's "a new integration." 

Common pitfalls to watch for: 

- Hardcoded field mappings buried in Apex instead of Custom Metadata — this is the #1 thing that makes the "just clone it" temptation so strong, and the #1 thing that makes maintenance painful later 

- Bulkification/governor limits — if the second integration runs concurrently with the first, make sure shared triggers/flows are bulk-safe, since now two integrations' worth of volume can hit the same automation 

- Error handling and retry logic tied to one specific API's response format — generalize this early, or you'll end up with API-specific error handling scattered everywhere