#Automation45 diskutieren mit

DZV can only use static values, i.e. a parameter, or a { FIXED } LoD at the level of the workbook (no Dimensions). So, not all Boolean fields will show in the DZV selection. Filtering is also carried out too late, i.e. you can't apply DZV based on filters, so your COUNTD() > 0 won't work. 

I would switch your [Mission ID] filter to be a Set (then you'd have your worksheet filters as being in our out of that set, visually indistinguishable from a normal Dimension filter). For the DZV, because Sets are 'independent' (they don't inherently do anything like filtering) you could then have

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

Essentially, I'm moving your filtering inside the COUNTD, looking at every row of data and checking if the rows that match the Mission ID have a Milesone Rank. Across the entire dataset, it checks if that count is greater than zero, giving one, workbook level Boolean value. 

Having the > 0 inside the { } is important, but I never remember why. If you have { .... } > 0 you will not be given it as a choice in the DZV list of fields. 

Hello @Mohamed Magdy

make sure you have well set up all lines with ID in your flow configuration items. See for example the note from within the trailhead unit : "Note: Make sure you select the Account ID option that has a Record data type, signified by a > in its row. Could you please also provide us a debug trace of your flow, or screenshots of your configured elements from within your flow ? 

Eric 

Hi @James K.k

The biggest win is usually reducing database operations, not just reducing Flow elements.

I’d bulkify the Flow around collections, eliminate Get Records/DML inside loops, and query only the fields/records actually needed. If the volume or logic still pushes governor limits, I’d move that part to Apex and let Flow handle the orchestration.

Hi Alessandro,

Regarding your design pattern for preserving historical audit records from short-lived staging sources in Data Cloud, here are the technical confirmations for how PySpark Custom Code Extensions handle write operations: 

1.WriteMode.APPEND Execution:Append Behavior. 

When using client.write_to_dmo(..., write_mode=WriteMode.APPEND), PySpark strictly appends new incoming rows to the target Data Model Object (DMO) or Data Lake Object (DLO) without truncating or wiping existing data. It will never automatically rebuild or clear out historical rows. 

2.Immunity to Full Refreshes:Platform Independence. 

PySpark code execution is completely separate from the platform-managed Full Refresh schedules used by standard UI Batch Data Transforms. Data Cloud will not automatically trigger a full rebuild or drop table operation on targets populated via Custom Code Extensions. 

3.WriteMode.MERGE and Source Deletions:Merge Behavior on Deletions. 

Under WriteMode.MERGE, records that are deleted or purged from the source staging table remain untouched and preserved in the target table. Merge updates or inserts matching records based on keys, but it does not propagate source deletions to remove historical records from the target.

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

This error (INVALID_CROSS_REFERENCE_KEY: Owner ID: owner cannot be blank) typically occurs for one of two main reasons when attempting to update Contact ownership from an Opportunity:

1. How is the Flow referencing the Contact? (Primary Suspect)

By default, standard Opportunities do not have a direct lookup to ContactId unless you are using:

• Custom fields (e.g., a custom Primary_Contact__c lookup).

• Opportunity Contact Roles (OpportunityContactRole).

Check your Update Records element:

• If your flow is trying to update records of type Contact using a filter like Id Equals $Record.ContactId (or an empty custom lookup field), that lookup value is resolving to null/blank.

• When Salesforce receives an update request for a Contact where the target record ID or lookup resolution fails/is null, it often misinterprets the payload and throws Owner ID: owner cannot be blank or an INVALID_CROSS_REFERENCE_KEY.

• Fix: Verify how your Opportunity finds the related Contact. If you use Opportunity Contact Roles:

• 1. Add a Get Records element to find the OpportunityContactRole where OpportunityId Equals $Record.Id (and optionally IsPrimary Equals True).
  2. Add a Decision element to check if a Contact Role was found ({!Get_Contact_Role} Is Null False).
  3. In your Update Records element, update the Contact where Id Equals {!Get_Contact_Role.ContactId}, setting OwnerId = $Record.OwnerId.

2. Is the New Opportunity Owner an Active User?

• Unlike Accounts, Leads, and Cases, Contacts cannot be owned by Queues—a Contact's OwnerId must always resolve to an active User ID (prefix 005).

• If your Flow is passing a Queue ID, or if the user being assigned is inactive or lacks the necessary license/permissions on the Contact object, Salesforce rejects the assignment with this cross-reference error.

• Ensure you are mapping:
  • Field: OwnerId
  • Value: {!$Record.OwnerId} (make sure you select the ID itself, not a related field like Owner:User > ContactId).

3. Contact "Private Record" Sharing Restriction

In Salesforce's standard data model, a Contact without an AccountId is considered a private contact and has strict ownership rules:

• If the related Contact is not associated with an Account, changing its owner requires specific permissions and cannot always inherit owners dynamically.

• Ensure the target Contact has an associated AccountId.

Quick Debugging Tip:

Run your flow using the Debug button in Flow Builder with the specific Opportunity record ID where you saw the failure. Look at the right-hand debug panel under the Update Records step—it will show the exact values being passed into OwnerId and Id.

Hope this helps track down the culprit!