{"id":7905,"date":"2026-03-16T21:01:26","date_gmt":"2026-03-17T03:01:26","guid":{"rendered":"https:\/\/gregsowell.com\/?p=7905"},"modified":"2026-03-16T21:01:26","modified_gmt":"2026-03-17T03:01:26","slug":"servicenow-to-ansible-event-driven-automation-the-easy-way","status":"publish","type":"post","link":"https:\/\/gregsowell.com\/?p=7905","title":{"rendered":"ServiceNow to Ansible Event Driven Automation The Easy Way"},"content":{"rendered":"

\"\"<\/a>
\nI first have to say that the technique pioneered here was completely engineered by my brother-from-another-mother Nick Arellano<\/a>. Connect with this brilliant dude on LinkedIn NOW!<\/p>\n

Introduction<\/h2>\n

There is a traditional method that allowed ServiceNOW(SNOW) to connect to the Ansible Automation Platform’s(AAP) API<\/a>, but while this worked, it was clunky.
\nIn short it would go from Service Catalog(SC) item => SNOW workflow => REST message => Oauth token.
\nIf you wanted to add a new SC, you would have to duplicate each one of those pieces save for the Oauth token…which becomes quite tedious. A lot of those pieces are often controlled by the “SNOW team”, which means it could take weeks or even months to have additions or changes done.<\/p>\n

Imagine if there was a better way(simpler and faster) \ud83d\ude42
\nThis better way is to have SNOW call Ansible’s Event Driven Automation(EDA).
\nThe process looks like Service Catalog item => business rule => REST message.
\n\"\"<\/a>
\nIn this configuration the REST message and business rule is created once by the SNOW team, and you don’t have to touch it after that.
\nThe business rule will grab all of the variables from the service catalog and pass them right over to EDA which will then kickoff an Ansible workflow or job template.
\nThis means I can create\/update my SNOW service catalog items whenever I want and I will immediately see the update!<\/p>\n

Demo<\/h2>\n