#Integration69 debatiendo

I believe that the name of the object needs to be passed -

const recordInput = {apiName: 'ORDER_OBJECT', fields};

this is passing the string literal 'ORDER_OBJECT' when you should be passing the variable-

const recordInput = {apiName: ORDER_OBJECT, fields};
or
const recordInput = {apiName: 'Customer_Order__c', fields};

For this pattern I'd use SAML SSO as the backbone, not token exchange. 

1. Identity: make the portal's IdP (or your corporate IdP, if both sit behind it) the SAML Identity Provider for Salesforce, with My Domain login enabled. Map each advisor using the Federation ID on their Salesforce User record, and send that same value in the SAML assertion. Each advisor still needs their own Salesforce user and license. 

2. Landing on a prefilled page: build the Lightning URL in the portal, for example /lightning/o/Task/new?defaultFieldValues=WhatId=<AccountId>, and pass it as the RelayState (or startURL) of an IdP-initiated SSO. If the advisor has no session, the SSO sets one up silently and they land on the prefilled form. If they already have a session, the deep link just opens. 

3. Attribution and permissions: because the record is created in the advisor's own browser session, ownership, sharing and field-level security all apply automatically. That's the main reason to avoid creating activities through an integration user. 

4. JWT bearer and token exchange are for API calls made on a user's behalf from your server. They don't give you a browser session, so they suit background sync, not opening Lightning pages. 

Common pitfall: Federation IDs drifting out of sync when users are created. Automate user provisioning (SCIM or JIT provisioning) from day one.

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.