I`ve stumbled upon this weird issue, where a simple runbook which needs to detect when an incident is changed and write the incident name into a text file gets triggered out of nowhere. So basically when looking in the service manager database under table MT_system$WorkItem$Incident_Log there was no timestamp for a change action, which means that service manager is right and the incident was not changed. Orchestrator on the other hand, seems to detect changes on incidents which are not "real", it basically detects also when an internal workflow touches the incident and triggers the runbook.
Great.. now depending on what the runbook does you can filter the monitoring object and set a <after> condition. The filter would look like
Where status before is not resolve
Where status after is resolve
Unfortunately for some enumeration types like status, we do not have that option:
I`ve filled a bug on the connect site for this connect.microsoft.com the ID is 918400, so please vote this up!:)
For more filter ideas check also How to execute Orchestrator Runbook from Service Manager and pass info to the Runbook (for example Incident ID):