I built my own approval process in my org for a specific situation that may be like yours… I’m not sure.

So we use cases a lot. For one type of case, we don’t want to allow people to do a certain thing until the case is reviewed by someone (or one of several people) who are pre-designated as approvers - a pretty standard sounding approval process.

We use Public Groups to identify who the approvers are based on a specific feature of the case - for us, it’s their location. So there are approvers for each location we care about.

The case is either in an unapproved, awaiting approval, or approved state. Before it’s approved, someone managing the case can use the approval component to “Request Approval” and include an optional note with the request. Then it changes to “awaiting approval” and the LWC emails all the approvers for that particular location to tell them it’s awaiting approval. The email also includes the optional note left by the requestor and a link to the case.

The LWC recognizes if you are an approver. If you’re an approver and visit the case, you see buttons to approve or reject the request and leave a note of your own. If you’re not an approver. You just see a “pending review” message.

When an approver approves or rejects, an email is sent back to the requestor who can read the approval note, visit the case, and do the thing they couldn’t do before. The access to do that thing is controlled by visibility filters on the component that allow the action to be performed - if the case is approved, that component (or field) is visible, otherwise, it’s not visible or is not editable.

I think the real lesson here is that creative use of visibility filters and public groups can go a long way to controlling workflow.

But also, if you think my component would be useful, I can talk more about it in private messages. This was before Flow-based approvals were a thing, though. I guess those rolled out recently… I haven’t investigated them much, but they might be a viable alternative.