#Answers4 discutindo

Hi Ravishankar - having done a couple of these (legal-entity vs operating/commercial splits), the single biggest decision - and the one that drives everything else - is: keep Legal Entity as an Account record type, don't make it a separate custom object. 

Recommended target architecture: 

- One Account object, two record types: Commercial Account (the selling/operating relationship) and Legal Entity (the contracting/billing/tax party). 

- Link them via Account Hierarchy (Parent Account) or a dedicated lookup (Legal_Entity) - hierarchy if it's a clean 1:many, a lookup/junction if a commercial account can map to different legal entities over time or geography. 

- Introduce account ROLES on the transactional objects instead of forcing one account: sold-to = Commercial Account, bill-to / contracting party = Legal Entity, via lookups on Opportunity/Quote/Order/Contract. 

Why not a custom object for Legal Entity: Contracts (Contract.AccountId), Orders, CPQ, Billing/Revenue Cloud, Assets and Entitlements all reference the standard Account. Making Legal Entity a custom object means losing all of that out-of-the-box and rebuilding it - a huge, avoidable cost. Record types keep standard functionality intact. 

Biggest risks: 

- Reparenting existing data (Opps, Contacts, Contracts, Assets, Cases) to the correct entity - the hardest part; plan the migration + validation carefully. 

- Sharing/visibility: OWD, role hierarchy and territories keyed on Account can shift when the structure changes - re-model sharing deliberately. 

- Reporting roll-ups: anything rolling up at account/hierarchy level needs rework for the two-tier model. 

- Duplicate/matching rules must distinguish the two record types. 

Processes that unexpectedly bite: 

- Quote-to-cash is where the split really lands. Decide sold-to (commercial) vs bill-to (legal entity) explicitly and thread it through Opportunity - Quote - Order - Contract - Invoice. 

- Territory assignment, approval routing, and case entitlements/SLAs that read Account fields. 

- Tax and consent/privacy, which usually belong to the Legal Entity. 

CPQ / Contracts / Billing / Reporting: 

- CPQ: quote on the Commercial Account, but carry the Legal Entity as bill-to (lookup) so contracts and orders bind to the right party. 

- Contract.AccountId points to the Legal Entity (contracting party); keep the commercial relationship as a related lookup. 

- Billing/Revenue Cloud: bill-to = Legal Entity. 

- Reporting: build for both tiers - commercial performance vs legal-entity consolidation - via the hierarchy/lookup. 

Approach / effort: 

- Start with an impact assessment: catalog everything referencing Account - objects with Account lookups, flows/triggers/validation rules, reports/dashboards, sharing rules, CPQ & billing config, and every integration keyed on Account Id / External Id. 

- Build and validate in a full sandbox, especially the CPQ/billing/reporting flows, before any cutover. 

- Phase it, and plan the data migration + External Id/MDM alignment with your ERP (which almost certainly already has a legal-entity / sold-to / bill-to model you'll want to map to). 

- For a large enterprise with CPQ + billing + integrations this is typically a multi-month program, not a config change - the data migration and quote-to-cash rework dominate the timeline. 

Happy to go deeper on the quote-to-cash role modeling or the sharing re-design - those are where the effort is usually underestimated.

@Sourav P

Yes. The answer is: 

In Salesforce, Custom Metadata records are maintained under: 

Setup → Custom Metadata Types → [Your Custom Metadata Type] → Manage Records 

There are two different things: 

• Custom Metadata Type → Defines the structure/fields. 
• Custom Metadata Record → Stores the actual values. 

If you can see the field name but not the actual value, click Edit on the specific metadata record. The values should be displayed there. 

For example: 

Custom Metadata Type: Application Settings 

 → Manage Records 

 → Default Settings 

 → Edit 

 → Update the field values. 

If the value is still not visible or editable, it may be coming from another source, such as: 

•  A Custom Label
• Custom Setting
• Custom Metadata referenced by Apex/Flow
•  A Formula
•  A Named Credential
•  A value hard-coded in Apex/LWC 

You can also check the Apex/Flow code that references the metadata to identify exactly where the value is being used. 

Hi Oraz,

If you're comfortable with joins, you may want to prepare a Logical Table as follows:

1) UNION the questions and comments tables (right in Tableau)

2) 'ALIGN' the 'same entity' columns using the Tableau-generated [Table Name] as the anchor:

// aligned_question_id
CASE [Table Name]
WHEN 'questions' THEN [id]
WHEN 'comments'  THEN [question_id]
END

// aligned_user_id
CASE [Table Name]
WHEN 'questions' THEN [answered_user_id]
WHEN 'comments'  THEN [user_id]
END

// aligned_date
[date]

3) JOIN the users table with the Unioned one by the [aligned_user_id] Join Calculation on the left

Step 3 has to be prepend the step 2, I just show the calcs first to explain the Join to be made.

Yours,

Yuri

Hi @Chris Uttley,

You can do that by upgrading your highlight panel on Lightning record page to Dynamic and then set conditional visibility on the button based on the permission set.

Check the attached screenshots.

Please mark as the best answer if this resolves your issue.

Thanks,

Milos

Unfortunately, something like this would have to be introduced at a platform level to apply to all / any component. Otherwise it would have to be done at a component level (to take in a custom CSS Class name as a property input and apply it to the parent wrapper of the component). So it's unlikely that there's anything on the appexchange that would address this.

Maybe create an idea to extend similar functionality from LWR to Aura?

FYI @Alicia Teo

Yes, could use Email Service or if you are using Email-To-Case, you can do it in Trigger.

One Visual Solution could be use Custom Notification for Visual effect:

https://help.salesforce.com/s/articleView?id=sf.notif_builder_custom.htm&type=5

Additionaly, the check in the Case could be used, if you want this solution, but should work with List View and Filter for the Checkbox field. That way your agents could review this cases with incoming emails received.

Thanks a lot,

Regards