ATF in Service Portal – Handling Custom Widgets

[Aaisha_ghodekar]

Hello SNC Consulting Community,

I am currently working with ATF (Automated Test Framework) in the Service Portal. Standard use cases are running smoothly, but there are challenges when it comes to custom widgets.

In this case, there is a custom widget that displays a list of Tasks. The goal is to:

1. Filter the list to find a Task.

2. Open the corresponding Task that was created in the previous ATF step.

The problem: the Task number is dynamically generated and unique for each run, so it cannot be hardcoded. I already tried using the "Click Custom Component" test step, but since the value changes every time, the step does not reliably identify the correct Task.

I also tried using a record query to capture the Task number and then open the record directly in the table. However, in this scenario there are custom widgets on the Service Portal page that are required to approve or decline the Task. When opening the table form directly, the page does not load the custom widget, it only shows the default form view. I also tried opening the record using a URL, but ran into the same issue.

Has anyone implemented a similar scenario with ATF and custom widgets? Are there best practices or recommended approaches for handling dynamically generated values in custom components?

Any tips or experiences would be highly appreciated. A short exchange call would also be welcome.

Thanks a bunch 🙂

[Ankur Bawiskar]

@Aaisha_ghodekar 

there will be issues since you are using custom widgets.

You can try to use "Custom UI Steps" and retrieve the element and then use ATF.

If my response helped please mark it correct and close the thread so that it benefits future readers.