Creating ATF Test to Dynamically Pick Up Approver and Approve Submitted RITM

jmiskey · ‎03-25-2020

I am trying to create a somewhat "dynamic" ATF Test. Basically, I want it to go out to the Service Portal, and make a specific Catalog Item Request. This request will create a RITM that kicks off a workflow that has an Approval and a Task and then closes out.

So what I would like it to do is after I submit the request via the Service Portal, I would like to, on the ServiceNow side, is find the RITM (which we can dynamically do by capturing the ID of the submitted Catalog Item), and hopefully find the selected Approver for that RITM, and then Impersonate that Approver, and have that Approver open up that specific Approval, and approve it. But I am not sure how to do that dynamically.

Here is what I have so far, which creates the request from the Service Portal side, but I am kind of stuck on the next steps.

I know I could hard-code the Impersonation of the Approver (the workflow sets the Approver equal to the Manager), but I would like to figure out a way to dynamically determine the Approver from the submitted RITM. Is that possible?

And then, how can we get to the correct Approval record to approve?

Thanks

Gerald Onyia · ‎03-25-2020

Question... how do you know who the Approval Task is supposed to go to? Is it the Requestor's Manager? Or is it a member of an Assignment Group for the Catalog Item?

Requestor Manager Scenario - Use a 'Create User' step above your Requestor's 'Create User' step to create a manager called "Joe Manager". Do not impersonate. Then in your current Step 2 (new Step 3), reference the 'Manager' field to Manager 'Create User' step. Once the Request is submitted:

Use the 'Record Query' step in the Request Item table to query the Requested Item whose 'Request' is (reference 'Order a Catalog Item' step)
Impersonate the (reference Manager 'Create user' step)
Then use another 'Record Query' in the Approval table to query the Approval whose 'Approval For' is (reference RITM 'Record Query' step)
Use 'Open Existing Record' step to open (reference Approval 'Record Query')
Use 'Click UI Action' step to click Approve, and done

Assignment Group Scenario - Use a 'Create User' step above your Requestor's 'Create User' step to create a user called "Joe Approver", and assign the Group to that user. Do not impersonate. Once the Request is submitted:

Use the 'Record Query' step in the Request Item table to query the Requested Item whose 'Request' is (reference 'Order a Catalog Item' step)
Impersonate the (reference Approver 'Create user' step)
Then use another 'Record Query' in the Approval table to query the Approval whose 'Approval For' is (reference RITM 'Record Query' step), and 'Approver' is (reference Approver 'Create User' step)
Use 'Open Existing Record' step to open (reference Approval 'Record Query')
Use 'Click UI Action' step to click Approve, and done

Hope this helps. Let me know if you have questions!

View solution in original post

jmiskey · ‎03-26-2020

UPDATE: I was working on "TASK" on got a little stuck on what to do about how to get someone from the Assignment Group, and then saw the second set of instructions from your post above. Though they did not apply to the Approver piece, the first few steps work perfectly for the Task piece! And I am happy to report that I got the whole Task piece of my project to work also.

So thank you once again!

Gerald Onyia · ‎03-26-2020

Glad to have helped! I've developed ATF Tests for over 200 catalog items. Some with a lot more complex workflow, including up to 10 Tasks, and validating data in other related Tables. Feel free to reach out if you have more questions!

jmiskey · ‎03-26-2020

Thanks Gerald.

I actually had something very odd happen. It worked great in out Dev environment, but when we promoted it up to our Test environment, I get an error. I know sometimes you get errors which you can ignore, but I am not sure how to tell if this is one of those errors.

First, here is a snapshot of the steps I added:

I get a failure on step 15, and it says:

"This step failed because the client error 'TypeError: Cannot read property 'id' of undefined' was detected on the page being tested. See failing Test Logs. To ignore these errors in the next test run, use 'Add all client errors to warning/ignored list' links."

Is this the type of error that it is safe to add to the "Ignored" list?

Thanks

Gerald Onyia · ‎03-26-2020

First off, your Step 12 and 13 can be combined. You can also impersonate within the 'Create User' step. For your Step 14, add a 'State' = "Open" validation. Otherwise, it might try to pull records that are closed, which you don't want. Other than that, it looks good to me. If the client error occurs again after making the changes, I would ignore it. I've ignored a decent amount of client runner errors. What your testing is the actual functionality and workflow.

jmiskey · ‎03-26-2020

Thank you. That is helpful.

I guess to be consistent, it would be probably be wise up in Step 9 to add a Condition there too on my Approval to make sure that State is Requested (and not already Approved or Rejected).