Regarding the behavior of resolved Cases when an email related to that Case is received, there are essentially 2 options, with a hybrid of the two as well. These options are produced by a setting on the automatic record creation rule that drives conversion of emails to Cases- it’s called “Wait for a specific amount of time after the connected case is resolved”.

Scenario A: “Wait for a specific amount of time” set to No. Email from external to monitored box initiates case. Email sent from within Dynamics creates tracking token, in email subject line. Case resolved. Reply to the outgoing email from external is associated with existing Case, but Case is not reopened.

Scenario B: “Wait for a specific amount of time” set to Yes, “Amount of time” set to blank. Email from external to monitored box initiates case. Email sent from within Dynamics creates CRM#. Case resolved. Reply to the outgoing email is not associated with existing Case, but a new Case is opened. The new Case does not contain the original email received or the response sent from Dynamics- those remain in the resolved Case.

Scenario C: “Wait for a specific amount of time” set to Yes, “Amount of time” set to 15m. This is essentially a hybrid- email responses to a Case associate, but do not reactivate the Case up to 15m after the Case was resolved, then after the 15m mark an email reply will open a new separate Case. It’s Scenario A up to the time specified, then Scenario B.

None of these are what we really want, which is for an email sent to a closed Case to associate, and cause it to reactivate. To attain that behavior (Scenario D) is probably possible using a PowerAutomate flow, but it would require a fair bit of work. There’s some logic linking separate entities that would be involved- compare email received date with any case resolution activity that might be associated with the Case related to that email, if email is newer than resolution then change Case status to “active”.)

Could you please create a baked-in way to implement Scenario D? Without it, we're forced to choose between dropping balls (Scenario A would cause incoming emails to roll up under resolved Cases that agents are not looking at) and fielding inquiries without the benefit of seeing prior correspondence (Scenario B). We primarily manage correspondence as Cases received via Views, as opposed to email queue items.