#Analytics31 discussing

Chris's set idea is the right way, I built it on Superstore to make sure it really drives the zone (screenshots below). A few details that made it work:  

Create a set on Mission ID (right-click the field > Create > Set) and use it in place of the Mission ID filter, so every sheet that was filtered by Mission ID now has the set on Filters showing IN. Then right-click the set > Show Set, and on the card's menu choose Single Value (dropdown). For your users it looks almost the same as the dropdown they have now, the only difference is there's no (All) option in single value mode.  

Keep the set dropdown outside the container you hide. If it sits inside it, it disappears with the section and nobody can switch back.  

The visibility field must be one value for the whole workbook, so the whole comparison goes inside the braces:  

{ FIXED : COUNTD(IF [Mission ID Set] THEN [Milestone Rank] END) > 0 }   

Written as { ... } > 0 it won't show up in the list, that's the bit Chris mentioned. And because it's a FIXED, normal filters don't affect it. If another filter on the dashboard should count too (date, region...), right click it and Add to Context.  

Put the milestone sheets in one tiled container, select the container, go to the Layout tab, tick Control visibility using value and pick the field. When it's False the container goes away and the tiled items around it take the space, so no blank area.  

In my test the field is "does the selected state have any order with a 50% or bigger discount": Texas shows the section, California hides it. Same structure as yours, just swap in Mission ID and Milestone Rank.  

I also have the same question about the overall flow of the dashboard. I think connecting gaming addiction risk with average daily gaming hours first and then moving into sleep hours and social isolation makes sense because it gives the viewer a natural progression from gaming behavior to possible related outcomes. I would mainly make sure each chart has a title that clearly tells the viewer what they are looking at rather than using short or generic labels. The takeaway statement should also be easy to understand on its own, so someone who has not seen the dataset before can quickly understand the main pattern without having to interpret every chart first. 

For the layout, I would try to keep the most important comparison visually prominent and make the other charts support that main story rather than competing for attention. Using the same color meaning throughout the dashboard would probably make it easier to compare the different risk levels, while too many colors could make the story harder to follow. I’d also check spacing, font sizes, axis labels, and whether any chart has unnecessary elements that could be removed. Overall, the story sounds clear, but I’d be interested in seeing how other people would arrange the charts so the connection between gaming behavior, sleep, and social isolation is immediately noticeable. A similar approach can be useful when looking at Free Fire beta, where keeping important information and comparisons visually clear can make it easier to understand what is changing between different versions or gameplay elements. Perfectly stated here  ffbeta.io

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