#Salesforce183 diskutieren mit

Hi Sabeer, 

Both of your ideas are solving this the hard way — the actual fix is a data model change, not a concurrency workaround. 

Best approach: create a child object (e.g., "Financial Analysis") related to the Financial record via a Lookup (or Master-Detail if you want rollups/cascade delete). Each analyst creates their own Financial Analysis record against the same parent Financial record — one record per analyst, not one shared record. 

Why this solves everything you listed: 

1. No concurrency/locking issue at all — each analyst is editing their own distinct record, never the same row, so there's no "someone else is editing this" conflict. 

2. Everyone still sees everyone else's work on the same screen — add a related list (or better, a Lightning page component/Dynamic Related List) showing all Financial Analysis child records on the parent Financial record page. All analysts land on the same parent record and see every analysis in that related list in real time (or on refresh). 

3. One place for the Reviewer — the Reviewer opens the single parent Financial record and sees all analyses in that one related list, rather than hunting across multiple separate records like your second idea would require. You can even add a Reviewer-only "Review Status" or "Approved" field directly on each child Analysis record so they can mark each one off in the same place. 

Optional enhancements once the base model is in place: 

- Use Record-Triggered Flow or a validation rule to prevent duplicate Analysis records per analyst per Financial record (one analyst, one analysis, enforced by a formula/validation on a unique key like Analyst + Financial Record). 

- If you want a roll-up summary (e.g., "X of Y analysts submitted"), a Master-Detail relationship gives you native Roll-Up Summary fields for that. 

- If the Reviewer needs a consolidated read-only view rather than scrolling a related list, a simple Lightning Web Component pulling all child records into a table/grid on the parent page works well too. 

This pattern (one child record per contributor, rolled up to a shared parent) is the standard Salesforce way to handle "many people annotate the same thing" without ever touching record locking.

Hi Venkat, 

Good discussion topic. Rather than picking one winner, here's what the data and Salesforce's own market direction actually show: 

Data 360 is the real foundation, not just another skill on the list. 

Salesforce's own Q3 FY26 earnings confirm Agentforce and Data 360 combined are now their fastest-growing revenue line, up 114% YoY to ~$1.4B ARR, with Data 360 ingesting 32 trillion records in a single quarter (up 119% YoY). More tellingly, Salesforce has architecturally folded Data Cloud into Data 360 as the mandatory data layer underneath Agentforce, agents are only as reliable as the data grounding them. This isn't marketing framing, it's a structural dependency: you cannot build a production-grade agent without clean, governed, unified data underneath it. 

Reference:

Agentforce is the visible layer, Data 360 is the plumbing. 

Most professionals will interact with Agentforce (the builder, agent scripting, orchestration), but the differentiated, harder-to-replicate skill will be Data 360 architecture: semantic data modeling, identity resolution, and governance. Agentforce adoption without solid Data 360 underneath is exactly what's producing "agent quietly creates cleanup work" failures being reported across 2026 implementations. 

Apex/LWC isn't going away, but its role is shifting. 

Programmatic skills remain essential for custom actions, complex orchestration logic, and Apex-invoked Agentforce actions, but they're becoming a supporting skill for AI workflows rather than the primary interface, less "build the whole feature in code," more "build the specific action an agent invokes." 

Integration is quietly becoming inseparable from Data 360. 

With Salesforce's Informatica acquisition now folded into Data 360 (bringing data catalog, MDM, and governance natively), integration skill is merging into the Data 360 skillset rather than remaining a separate specialty. If you're building integration expertise, doing it through a Data 360/MuleSoft lens rather than pure point-to-point API work is the more future-proof framing. 

My honest read: if you can only deepen one area over the next 2-3 years, Data 360 (data modeling, governance, identity resolution) has the strongest structural case, it's the layer every other skill (Agentforce, Apex actions, integrations) increasingly depends on to actually work reliably in production, not just in a demo.