#Integration65 discussing

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

Hi Suraj,

To write a unit test for a @future (callout=true) method, you need to mock the HTTP callout (using HttpCalloutMock) and enclose the execution between Test.startTest() and Test.stopTest(). Salesforce runs all asynchronous methods (like future methods) called within startTest() and stopTest() synchronously right when Test.stopTest() executes. 

Here is an example test class structure to cover your method:

1.Create a Mock Callout Class:

Mock Implementation. 

Create a mock class that implements HttpCalloutMock to return a fake JSON response simulating your patchCall output (ensuring it contains 'state' => 'Success' and a valid JSON structure with an id field).

2.Prepare Test Data and Context:

Test Setup. 

In your test method, insert a test Bid_Review_Request__c record so that the update brUpdate; statement can successfully find and update a record in the database.

3.Wrap in Start/Stop Test:

Execution and Assertion. 

Assign your mock, wrap the future method call inside Test.startTest() and Test.stopTest(), and assert that the record was updated successfully.

Apex 

@isTest
private class NewProjectHandlerTopUpTest {
    // 1. Mock class for HTTP callouts
    public class MockHttpResponseGenerator implements HttpCalloutMock {
        public HTTPResponse respond(HTTPRequest req) {
            HttpResponse res = new HttpResponse();
            res.setHeader('Content-Type', 'application/json');
            res.setStatusCode(200);
            // Construct JSON response matching the parser requirements
            res.setBody('{"state": "Success", "resBody": "{\\"id\\": \\"12345\\"}"}');
            return res;
        }
    }
    @isTest
    static void testNewProjectHandlerTopUp() {
        // Create test record to satisfy update operation
        Bid_Review_Request__c testReq = new Bid_Review_Request__c(
            Name = 'Test Project'
            // Add required fields for Bid_Review_Request__c here
        );
        insert testReq;
        Map<String, String> recordMap = new Map<String, String>{
            'ID' => testReq.Id,
            'Name' => 'Test Project'
        };
        // Set mock callout
        Test.setMock(HttpCalloutMock.class, new MockHttpResponseGenerator());
        Test.startTest();
        // Calling the future method
        YourClassName.newProjectHandlerTopUp(recordMap, '{"test":"json"}', 'destination', 'WBS123');
        Test.stopTest(); // Future method executes here
        // Assertions to verify the record was updated
        Bid_Review_Request__c updatedReq = [SELECT WBS_Project__c FROM Bid_Review_Request__c WHERE Id = :testReq.Id];
        System.assertEquals('12345', updatedReq.WBS_Project__c, 'The WBS Project code should be updated successfully.');
    }
}

(Note: Replace YourClassName with the actual name of the Apex class containing your future method).

Hi Branden, if the new picklist values are already added to the relevant Record Types but still aren’t showing, I’d also check the field-level configuration and confirm the values are Active.

Also verify that you’re testing with the expected Record Type and that the picklist field isn’t being restricted by a dependent picklist or another configuration. 

If it still doesn’t appear, could you share the picklist field, Record Type, and a screenshot of the Picklist Values and Record Type settings? That would help narrow it down. 

Hi Vikrant, autocomplete="off" isn't supported directly by lightning-input-field because it doesn't expose the underlying <input> element's autocomplete attribute. 

If you need to control autocomplete, you can use lightning-input instead of lightning-input-field and set: 

<lightning-input
    type="text"
    autocomplete="off"
    name="myField">
</lightning-input>

If you need to keep lightning-record-edit-form and lightning-input-field, you generally can't reliably disable the browser's autocomplete through the component attribute. 

If you can share which field you're trying to disable autocomplete for and what browser you're testing in, I can suggest a more specific workaround. 

Hi SidParnam,

If you're maintaining a long list of company names in a formula, I wouldn't recommend moving the same large IF/OR logic into Apex. Apex doesn't have the formula field's 5,000-character limit, but hard-coding a large company list makes the solution difficult to maintain.

A better approach would be to store the company values as configuration:

• Create a Custom Metadata Type with the company name and the checkbox value.
• Use a before-save Record-Triggered Flow to look up the company and set the checkbox.
• If you need more complex processing or a very large dataset, Apex can also query the configuration and update the record.

This way, adding or removing a company doesn't require changing and redeploying your formula/Apex code. 

If you share approximately how many company values you have and whether the checkbox needs to update immediately when the Company field changes, we can suggest the simplest implementation. 

Hi Brenna,

The INVALID_CROSS_REFERENCE_KEY on RecordTypeId usually means Salesforce can't use the Record Type ID being sent by the integration for that transaction.

Even if the integration user has the correct permissions, I would check:

• Confirm that 0123F000002c926QAA actually exists in the target org and belongs to the object being inserted/updated.
• Check whether the Record Type was recently deleted and recreated. A recreated Record Type gets a new ID, so an integration using the old ID will fail.
• Verify the integration is pointing to the correct org/environment. Record Type IDs are org-specific and shouldn't generally be hard-coded between environments.
• Check the integration payload/logs to see where that RecordTypeId is coming from.
• Verify the Record Type is available to the integration user's profile/permission set.

If you can't find that ID in Setup or through a query, I would especially suspect a stale Record Type ID in the integration configuration or source system. 

If you can share the object being created/updated and the relevant integration payload (with sensitive data removed), it would help narrow down the cause.