Bug: Inconsistent parameter when getting entity Host info (MdatpDeviceId vs MdeDeviceId)
Describe the bug When using the "Isolate endpoint - MDE" playbook template some inconsistent data is being sent to the logic app. The data references a parameter which seems to change depending on how the playbook was ran (triggered vs manually).
To Reproduce Steps to reproduce the behavior:
- Use the "Isolate endpoint - MDE" playbook template to create a playbook
- Setup all the appropriate permissions for the logic app to isolate a device and write comments to the incident
- Create an Automation rule with Trigger: "When incident is created" and choose the newly created playbook
- Trigger an incident in MDE, wait until it streams to Sentinel.
- Notice that the playbook fails because logic app references the "MdatpDeviceId" value which does not exist, instead "MdeDeviceId" was being given in the input.
- Now go back to the Incident --> Actions --> Run playbook and choose the same playbook that was triggered automatically
- Notice that it now succeeded to run the logic app as now the Entity host info contains "MdatpDeviceId" and no longer "MdeDeviceId".
Expected behavior The deviceId parameter should be either be MdeDeviceId or MdatpDeviceId all the time not change depending on circumstances of running the playbook. It would seem there is some sort of naming migration going on in the backend which breaks this playbook template.
Screenshots

Additional context M365 E5 License
Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.
Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.
Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.
Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.
Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.
Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.
Hi @brolifen, Thanks for flagging this. There is an open PR with the fix, you can track the status here for the same. Thanks
The PR for this fix is merged in master so closing this issue.
Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.