#Integration66 人がディスカッション中

We did a very similar Salesforce to NetSuite sync with Celigo a couple of years back and it worked well for us. Setup is honestly pretty approachable, lots of prebuilt templates for the common flows like invoice and payment sync, and their support team is solid when you hit a weird NetSuite mapping issue. MuleSoft is more powerful and flexible but in my experience it is overkill unless you have a dedicated integration person, the learning curve is steep and the cost is in a different league. For a straightforward flow like yours, I would start with Celigo and only look at MuleSoft if you outgrow it.

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.