CSM Create Case UI Action not visible on interactions created from OOB email flow

[MelissaS0144719]

I created a new case type for CSM and have activated the multiselect Create Case action. 

As you can see, when the type of interaction is phone (or manually created no matter what the type is), the Create Case action is working as expected. 

But when the case is created via the OOB 'Create Interaction from Email' flow, the Create Case action is missing. I (as admin) can see the Create Case action, but someone from the MH group is unable to see it.

I have given the following roles to the MH group.
-interaction_agent
-sn_customerservice.relationship_agent
-sn_customerservice_agent
-x_abcsm_csm_mule.mulehide_case_user (custom role for the new case type)

I enabled the OOB flow - 'Create Interaction from Email'
When interactions are created manually through the CSM Workspace, no matter the state, the Create Case action is visible and I am able to select it as expected, whether i am me (admin) or i impersonate a user from the MH group.
When an email creates an interaction, I (as admin) am able to see the create case action but while impersonating MH user, the action is not available.

[Naveen20]

Declarative Action visibility conditions or ACLs rely on the fact that it works for admin but not for the MH group user is the key clue — admin bypasses most ACL checks, so the underlying access control is failing silently for the non-admin user.

Here's what to investigate, in order of likelihood:

1. Compare field values between the two interactions

Open both interactions side-by-side (the manually created one and the email-created one) and compare key fields: assignment_group, assigned_to, account, contact, opened_for, channel, and state. The email flow likely isn't populating one or more of these that the action's visibility depends on. In particular, check whether the email-created interaction has the correct Assignment Group set — if it's empty or set to a group the impersonated user isn't a member of, that alone can suppress workspace actions.

2. Check the Declarative Action Assignment for "Create Case"

Navigate to sys_declarative_action_assignment and find the "Create Case" action assignment for the interaction table. Look at the Condition field — it may have a condition like assignment_group is member of current user or a state-based filter that the email-created interaction doesn't satisfy. Also check the Action Model it points to for any additional conditions.

3. Check ACLs on the interaction record

Since admin sees it but the non-admin doesn't, there's likely an ACL evaluating against the record. Check ACLs on interaction with operation read or any custom ACL type. Also check if there are Before Business Rules or ACLs on sn_customerservice_case (create operation) that evaluate the source interaction's fields — if the email-created interaction is missing account or contact, a create ACL on the case table could fail and suppress the action.

4. Update the "Create Interaction from Email" flow

Once you identify the missing field(s), modify the OOB flow (or create a copy of it) to ensure those fields are populated during interaction creation. Common fields to add: assignment_group, account, contact/opened_for. The flow likely only sets basic fields like short_description, channel=email, and direction=inbound.

5. Quick debug tip

Impersonate the MH user, open the email-created interaction, and check the browser's Network tab — filter for declarative_action API calls. The response payload sometimes includes reasons why specific actions were filtered out, which can point you directly to the failing condition or ACL.

In most cases I've seen, the root cause ends up being the assignment_group not being set on email-created interactions, which causes a group membership check to fail for non-admin users.