#Apex54 discussing

You’re correct that there isn’t a direct trigger point here. ProcessInstanceWorkitem doesn’t support Apex triggers or record-triggered flows, and reassigning the approval doesn’t update the Case itself. 

If you need to keep the standard Reassign action, I’d handle it with scheduled Apex:

1.  Run a scheduled job every few minutes. 
2.  Query new ProcessInstanceStep records where StepStatus = 'Reassigned'. 
3.  Use ProcessInstance.TargetObjectId to identify the related Case. 
4.  Query the pending ProcessInstanceWorkitem for that process instance to get the newly assigned ActorId. 
5.  Insert a FeedItem with the Case ID as ParentId. 
6.  Store the processed ProcessInstanceStep.Id in a small custom log object with a unique/external-ID field. 
7.  Skip any step already in that log so rerunning the job can’t create duplicate Chatter posts. 

I’d also test it by reassigning the same approval twice and then running the job twice. The expected result should be two Chatter posts total, with no additional posts from the second job run. 

If real-time posting is absolutely required, the other option is to replace the standard Reassign experience with a custom Flow/LWC backed by Apex. That custom action would update ProcessInstanceWorkitem.ActorId and create the Case FeedItem in the same transaction. But the existing standard Reassign action can’t be intercepted directly.

Short answer: you generally cannot (and do not need to) write QuoteAccountId into the standard Quote.AccountId field. On the Quote object, AccountId is a system-derived, read-only reference that Salesforce fills from the related Opportunity's Account. It is not createable/updateable through the UI, Flow, Apex or the API, so an update like AccountId = QuoteAccountId will be rejected or ignored. For quotes created without an Opportunity, QuoteAccountId (label "Account for Quote") is the field Salesforce intends you to use as the account relationship. 

For your future Order process this is already covered: Salesforce's documentation for quotes without opportunities says associating the quote to an account is optional but recommended, because an account is required to convert the quote to an order. When you create an Order from such a quote, the account comes from the quote's account (QuoteAccountId), so you don't need Quote.AccountId populated. 

Practical recommendations: 

1. Make QuoteAccountId required (validation rule, e.g. ISBLANK(OpportunityId) && ISBLANK(QuoteAccountId)) so every quote can be turned into an Order. 

2. After enabling the feature, open Object Manager > Quote > Fields > Account for Quote and grant field-level security to your profiles/permission sets. It is hidden by default, which is why it often looks unavailable in Flow, reports and Apex. 

3. In reports, flows, sharing logic and Apex, use one source of truth, for example a formula field BLANKVALUE(QuoteAccountId, Opportunity.AccountId), so logic works for quotes with and without an Opportunity. 

4. If you create Orders yourself via Flow/Apex (rather than the standard Create Order action), set Order.AccountId = Quote.QuoteAccountId and Order.QuoteId = Quote.Id. 

References: 

Enable Quote Creation Without a Related Opportunity:

Release note, Create Quotes Without a Related Opportunity:

Quote object reference:

Assumption: the statement that Quote.AccountId is read-only is based on the Quote object reference field properties and commonly reported org behaviour; please confirm in a sandbox (e.g. attempt the update in a Flow or Developer Console) before designing around it.

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.

@durgam santhosh

Yes - the native no-Apex route is an Email Alert (the core 'Send Email' Flow action won't render a template's merge fields). Create an Email Alert on Opportunity (Setup > Email Alerts) that uses your Opportunity Lightning template, then call it from your record-triggered Flow as an Action - the alert sets the triggering Opportunity as the Related To, so all your Opportunity merge fields resolve. 

For recipients you can pick Opportunity Owner directly; to send to that custom email field it has to be an Email-type field, then it shows up under Recipient Type 'Email Field'. 

If this helps, please mark it as the Best Answer so it helps the next person - thanks!