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

Hi Guilherme, Custom Keys aren’t required for basic push notifications. They’re used when the app needs to receive additional key-value data in the push payload, for example to support tracking, deep linking, or custom app behavior. The mobile app code needs to be implemented to handle those keys. 

For the basic MC Next setup, you’ll need to configure the mobile app and the appropriate iOS/Android push service credentials, then configure the SDK in the app to receive push notifications. 

So if the implementation doesn’t require any custom data or app-specific behavior, Custom Keys generally aren’t necessary. If you share what the other company is asking you to configure as the Custom Keys, it may be easier to determine whether they’re actually needed. 

@Jaishree Chundawat

If you are not able to see query studio then please check if you have assigned the license to yourself from setup. 

Here are the steps - Login to SFMC > hover on your name in the top right corner > go to platform tools > Apps > Installed packages > search and click on Query Studio > click licenses > select the BU where you want to assign query studio > find your user from "find users" > check the box in front of it > click save. 

Hope this helps!

@Charles Spring There are a few checks that you can perfrom - 

1. Check if journey status is active.
2. If it is associated with an automation - review the automation as well.
3. If above two are in place and records are being added in the data extension then check the contact evaluation. Click on entry source and then click "View Event Results" > Contacts Evaluated. See screen-shot for better understanding -

Please share your finding here if everything above looks fine in your journey.

@Taylor Thomas

If you don't want to use the SQL queries then you can utilize measures. This is not widely used feature anymore because everyone prefer to write code instead of looking for an out of the box solution. 

Review this help document -

Once you will configure your measure, you can then use it in the fliter criteria while creating filtered data extension too.

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

@Taylor Thomas

Good that rules out the most common silent failure cause, so this now points toward reputation/engagement rather than authentication. With 65k/123k on Gmail, you're well past the bulk sender threshold, so their spam-rate and engagement bar applies fully to you. 

1. Gmail Postmaster Tools - do this first, it's the actual source of truth Everything above is inference from opens; Postmaster gives you Gmail's own view: 

• Spam rate - this is the one that matters most. Gmail wants this under 0.10%, and anything approaching 0.3% risks bulk filtering. Marketing Cloud's own complaint tracking undercounts this people who just hit "report spam" without unsubscribing don't always show up the same way in MC's complaint metrics.
• Domain/IP reputation High/Medium/Low/Bad bucket, tracked daily
• Delivery errors and feedback loop data
• Needs domain verification (TXT record) if not already set up, this alone is worth doing regardless of the current issue, since you'll want the historical trend once you have it.

2. Segment your engagement report by ISP before doing anything else

If open rate dropped roughly evenly across Gmail/Yahoo/Outlook, that points more toward content/list fatigue than a Gmail specific inbox placement issue. If it's disproportionately Gmail, that confirms reputation/spam rate as the driver. This one check tells you which of the two paths below to prioritize. 

Since authentication passes, a spam rate creep is the next most likely explanation for exactly this symptom (delivered flat, opens down). Things that quietly push spam rate up: 

• A list merge/import around July/Aug that added lower-quality or older contacts
• No visible/working one-click unsubscribe (Gmail requires the List Unsubscribe header AND that it actually works within 2 days) if someone can't easily unsubscribe, they hit "report spam" instead
• Content changes (new sender name, new link domains, more images) that shifted spam filter scoring independent of reputation

4. Sunset flow before mass suppression

Once you know the spam rate and whether it's Gmail specific, then move to hygiene but sequence it: 

• Re-engagement send to 90+ day unengaged (low risk subject line ask if they still want these)
• Suppress non responders after that, rather than a single large deletion a sudden big cut can itself cause a short-term reputation dip right when you're trying to recover