#Financial Services Cloud21 discutindo

Hi Martin - the activity composer options (the tabs you 'submit directly' from in the timeline) don't come from the Activity Timeline component itself - they come from the page layout's 'Salesforce Mobile and Lightning Experience Actions' for that object. So your 'Compliance Task' option shows on the Financial Account page because a custom quick action (a Create-a-Record > Task action defaulted to the Compliance Task record type) sits in that object's page-layout actions, and it's simply missing from the other objects' layouts. 

To get it on the other pages: 

1. Find the action: Setup > Object Manager > Financial Account > Page Layouts > (the layout you use) > 'Salesforce Mobile and Lightning Experience Actions' - locate the Compliance Task action and note whether it's a Global action or a Financial-Account-specific one. 

2. If it's a global quick action: add it to the 'Salesforce Mobile and Lightning Experience Actions' section on the Account page layouts too - and remember Person, Household, and Institution are Account record types in FSC, so add it to each Account layout those record types use (check Page Layout Assignment). 

3. If it's an object-specific action on Financial Account: you can't reuse it on Account, so create an equivalent object-specific quick action on Account (New > Create a Record > Task, then default the record type to Compliance Task) and add that to those layouts. 

4. Confirm the Compliance Task record type is assigned to the relevant profiles - it clearly is where it works, but worth checking for the profiles hitting the other pages. 

The mental model: the composer follows each object's page layout, and each object (and record type) can use a different layout - that's why it appears on one and not the others. Add the action to those layouts and it'll show everywhere. 

Hope that sorts it!

HI @Martin Dahlquist If the standard rollup settings are already enabled, no additional Flow is normally required. Activity rollups only work when the task is related through the expected relationship (for ex : the Related To (WhatId) points to the Financial Account and the Financial Account is correctly linked to the Person Account and Household). If tasks are being created in bulk through automation or an integration, verify that the WhatId and related records are populated correctly. If everything is configured correctly and the rollup still doesn't occur, it may be a limitation of how the tasks are being created or a product-specific issue worth checking in the debug logs or with Salesforce Support.

Hello,

There doesn't appear to be a standard or packaged field for these purposes.

However the Task Object does have a relationship to the Action Plan Item Object.

When a Task is created as a result of a Item a Record in this Object is created and the Task is stored in the ItemId field.

Therefore using a Record Triggered Flow on Task Creation (or something similar) you could search for a matching Action Plan Item. If one is found you can then take the necessary action for example checkbox = TRUE.

Thanks, Tom

@Sarah Chen

The reason the validation fires when you edit the Household in the relationship map but not when you create the Account Contact Relationship is that these are two different code paths writing to two different objects, and only one of them runs the membership validation. 

When you add a relationship through the Related Contacts list, you're creating an AccountContactRelation record. That's the standard association of a contact to an account, and it does not enforce Household membership rules, because an ACR is just a relationship link, not a membership assertion. Your CPA and attorney contacts, parented to their own accounts, link fine here.

When you open the Household group in the relationship map and save, you're invoking FSC's group membership logic, which writes to the AccountContactRelation with the Household context but runs through the FSC-managed validation that governs who can be a member of a Household. That validation enforces the rule you're hitting: in FSC, Household members are modeled as individuals, and FSC expects Household membership to resolve to Person Accounts (or the individual model equivalent). The relationship map's save path re-evaluates all members of the group against that rule, which is why it throws even when you made no change, it's validating the whole group membership on save, and your externally-parented business contacts fail that check because they aren't Person Accounts. 

So to your specific questions.

Is there a hidden Account-to-Account relationship created? Not exactly an Account-to-Account record, but yes, there's more happening under the covers than a single link. FSC's group membership and the relationship map operate on the group's member set, and the map's save recomputes and validates that full set. The ACR creation path skips that group-level validation entirely, which is the whole reason you see the discrepancy. It's not that one creates a hidden object the other doesn't, it's that one triggers the group membership validator and the other doesn't touch it. 

Is there no way to relate contacts to Households in FSC? You can relate them, you just can't make them Household members through the relationship map, and that distinction is the crux. The relationship exists and is valid at the ACR level. What fails is trying to represent professional contacts as members of the Household group, because FSC reserves Household membership for the individuals who belong to that household, not their external advisors. 

The approach I'd take: keep the professional contacts linked via AccountContactRelation, which you've already got working, and surface them at the Household level through a related list or a custom Lightning component on the Household record rather than through group membership. You get the household-level visibility the firm wants without triggering the membership validator, because you're presenting the relationships in the household context rather than asserting them as members. If the driver is really "we want to see the household's professional advisors in one place," that's a presentation problem, solvable with a related list or component, not a membership problem.

If you genuinely need these to behave as first-class relationships with reciprocal roles, FSC's Reciprocal Relationships (the party-to-party relationship model) is the sanctioned path, and you can configure role types like CPA and Attorney there. It's slightly more to maintain than your single-ACR wish, but it's the model-aligned way and it won't fight you on save.