#Nonprofit33 personnes en discutent

Hi Catherine!

If this is happening for only one household, while the Timeline App works normally for other households, I’d first suspect something specific to that household record or its related data rather than a general Timeline configuration issue.

A few things I’d check:

• Try the same household with another Salesforce user to see if the logged-in email is still auto-populated.
• Check whether the household or its related Contact records contain that email in an unexpected field.
• Compare the affected household with a household where Timeline works correctly.
• Check whether there are any browser autofill extensions or saved form values, although the fact that it removes the Timeline items makes the app behavior worth investigating.
• Clear the browser cache/site data and test in an incognito/private window.

If the email still gets inserted for that household across different users/browsers, I’d capture the record IDs and contact the Timeline App vendor, since it may be a data-specific issue or app bug. 

If you can share the Timeline App version and whether this happens for other users on the same household, that would help narrow it down. 

Hi Kelley! 

Welcome to Salesforce! For a nonprofit, I’d start with the data model and reporting requirements before changing the screens. Coming from Blackbaud or DonorPerfect, some Salesforce concepts can feel different at first. 

For the CRM design, I’d look at:

• Accounts/Contacts for individuals, households, organizations, and relationships
• Campaigns for fundraising campaigns and outreach
• Opportunities for donations, pledges, and other revenue
• GAU Allocations if you need to track how donations are distributed across funds/programs
• Reports and dashboards designed around the reconciliation information your accounting team needs

I’d also avoid adding fields just to reproduce the old system. First identify the reports your team relies on today, then map each required piece of information to the Salesforce data model.

For nonprofit-specific guidance, the Salesforce Trailblazer Community’s Nonprofit group and Salesforce’s nonprofit resources are good places to compare approaches with other organizations. 

If you share which Salesforce nonprofit package/version you’re using (for example, NPSP) and what your current donation/account screens look like, the community can give much more specific recommendations.

Hi Heath, 

This is a real SLDS 2 rendering behavior, not a config mistake on your end — global actions with longer labels get visually compressed differently under SLDS 2 vs SLDS 1 styling, and there's no admin-facing setting yet to control icon/label sizing in that specific menu. 

Practical options right now: 

1. Revert to SLDS 1 for this sandbox while testing. Setup → Themes and Branding → select an SLDS 1 theme → Activate. This is a fully supported toggle (not a hack), so you can confirm your global actions render as expected under SLDS 1 while you evaluate SLDS 2 elsewhere, without being blocked by this specific issue. 

2. Report it through the official channel rather than working around it silently. Since SLDS 2 is still actively being refined post-GA, this is exactly the kind of feedback Salesforce wants — submit it via the Design System Roadmap feedback link (Trailhead's SLDS 2 support module points to it) so it's tracked against the actual component team, not just a community workaround. 

3. As a partial mitigation if you do stay on SLDS 2: since the truncation is driven by label length, consider whether the action's Label (display name) can be shortened while keeping a more descriptive Description/tooltip — I know you said shortening isn't always possible, but for actions where a shorter label + longer help text would work, that's the only user-facing lever available today without a platform fix. 

There's currently no styling hook exposed to override how global action menu items handle long labels + icons together under SLDS 2 — this is genuinely on Salesforce's side to fix in a future refinement, not something fixable via custom CSS/styling hooks from your org. 

Reference:

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 Mohammed,

Looking at your screenshot, the error message reads: "The 'Solarbot Pipeline by Stage' component is the incorrect size or in classe incorrect position."

In Salesforce Lightning Dashboards, the automated checker strictly verifies the exact grid dimensions (width and height) and coordinate placement of each component. Based on your layout, the SolarBot Pipeline by Stage component is currently positioned spanning across the left side, but its height or column span does not match the precise specifications required by the superbadge instructions.

1.Open Dashboard Builder:Dashboard Layout. 

Open the SolarBot Impact Dashboard in Edit mode. You can verify success when you see the grid configuration handles on your dashboard components. 

2.Adjust Component Width and Height:Component Sizing. 

Click and drag the corners of the SolarBot Pipeline by Stage component to match the standard sizing and layout guidelines specified in the superbadge instructions (typically a specific number of columns wide and rows high, ensuring it aligns symmetrically with neighboring components). You can verify success when the component grid boundaries snap to the correct layout proportions. 

3.Save, Refresh, and Re-run:Save and Check. 

Click Save, refresh the dashboard view, return to Trailhead, and click Check Challenge. You can verify success when the green completion checkmark appears.

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 Patrick,

Could you share the exact HTML error message you're getting and the type of email template you're creating (Lightning, Classic, or Visualforce)? 

If possible, also share the HTML/code you're trying to save and a screenshot of the error. The solution can depend on the template type and the specific HTML being used. 

With those details, someone should be able to pinpoint the issue.