@pavani_paluri Thank you. As it turns out, the problem was not on the ServiceNow side. There was a discrepancy between the automation administrator and the ServiceNow administrator. apparently, they have to be one and the same.
Let me explain in case this issue arises in the future for others trying to automate SN. Here is the Ansible automation block opening a change request (this worked fine for Incidents creation, BTW!):
The purpose of using the variables is that we create a VAR file looking like this:
The VARs file is read only once, so there is no need to paste the credentials each time the ServiceNow ITSM is called to create/alter/delete an Incident or a Change Request. Another upside of using a VARs file is that it can be placed in the Vault and encrypted. So, eve the automation software doesn't see the credentials while it is using them.
However, in my case I made a mistake. The vars file had the default PDI creator account in it, the "aes.creator". So, it kept failing. But once the Ansible user that is logging into ServiceNow (the VARs file) became the same as the user running the ServiceNow ITSM the problem disappeared. I am now able to create CRs via an Automation API, even upload logs and files as attachments before closing:
So, to reiterate, this was my issue. I should have known better. ServiceNow was not to blame. It did what it was supposed to do.
In any case, thank you for your help and please keep an eye for my future questions. I am new to SN and I am getting more and more fascinated by the product. It is much more than just a place to get my assignments from.
Nestor.
