QMetry: Fetch Test Case Runs by Test Suite Run

Get test case runs under a specific test suite run execution in QMetry, including Test Run UDF values. ALWAYS present results as a unified table: Test Case Key | Test Case Summary | Executed Version | Execution Status | <UDF Label columns…>. NEVER show a separate type+value breakdown — always combine identification fields and UDF values in one table per run.

Toolset: Test Suites

Parameters:

• projectKey (string): Project key - unique identifier for the project (default: "default")

• baseUrl (string): The base URL for the QMetry instance (must be a valid URL)

• tsrunID (string) required: Test Suite Run ID. CRITICAL: the parameter name is 'tsrunID' — do NOT use 'testSuiteRunId', 'tsRunID', 'testSuiteRunID', or any other variant. Accepts a string or number (e.g. 731600 or '731600' — both are valid). To get this value: Call 'Fetch Executions by Test Suite' → use data[].tsRunID from the response.

• viewId (number): ViewId for test execution - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.TE.viewId automatically. Manual viewId only needed if you want to override the automatic resolution.

• start (number): Start index for pagination - defaults to 0 (default: 0)

• page (number): Page number to return (starts from 1) (default: 1)

• limit (number): Number of records (default 10). (default: 10)

• filter (string): Filter criteria as JSON string (default '[]') (default: "[]")

• udfFilter (string): User-defined field filter as JSON string (default '[]') (default: "[]")

• tcrUdfFilter (string): Test Case Run (TCR) UDF filter as JSON string (default '[]'). Used to filter test case runs by Test Run UDF field values. Format: '[{"type":"list","value":[,],"field":""}]'. Example: '[{"type":"list","value":[5108701,5108697],"field":"8260LUP"}]' filters runs where the UDF field '8260LUP' has those list item IDs. (default: "[]")

• showTcWithDefects (boolean): Show test case runs with linked defects (default: false)

Output Description: JSON object with test case runs array. Each row ALWAYS contains these mandatory identification fields: 'entityKey' (Test Case Key, e.g. 'MAC-TC-123'), 'summary' (Test Case Summary/name), 'latestVersion' (Executed Version, e.g. 'v1', 'v2'), 'runStatus' (Execution Status label, e.g. 'Passed', 'Failed', 'Not Run'), 'runStatusID' (numeric status ID), 'tcRunID' (numeric Test Run ID), and 'testRunUdfs' (object with Test Run UDF field keys mapped to their values, parsed from the raw 'udfjson' field; HTML stripped from rich text). UDF values can also be fetched in enriched form via FETCH_TEST_RUN_UDF_VALUES or field metadata via FETCH_TEST_RUN_UDF_METADATA. The top-level response includes 'hasTcRunUdf' (boolean), 'total' (count), and pagination metadata.

Use Cases: 1. Get all test case runs under a specific test suite run execution 2. Fetch Test Run UDF values for all test case executions in a test suite run — always show Test Case Key, Summary, and Execution Status alongside UDFs 3. Fetch Test Run UDF values for a specific test case execution by tcRunID 4. Filter test case runs by Test Run UDF field values (e.g. show only runs where dropdown UDF = specific option) 5. Analyze individual test case execution results, status, and custom UDF metadata 6. Monitor test case run performance and execution trends 7. Generate detailed test execution reports including custom UDF data 8. Track test case run history and execution patterns 9. Validate test case run coverage and execution completeness 10. Audit test case run data with UDF values for compliance and quality assurance 11. Export detailed test case run data including Test Run UDFs for external reporting 12. Retrieve paginated test case run results for large test suite executions

Examples:

1. Get all test case runs for test suite run ID '107021'

{
  "tsrunID": "107021",
  "viewId": 6887
}

Expected Output: Present as ONE unified table — never as a separate type+value breakdown. Example: | Test Case Key | Test Case Summary | Executed Version | Execution Status | Tested By | Environments UDF | Execution Type | Country | | MAC-TC-5 | Login - valid credential | v1 | Passed | varis | chrome, edge, safari | Functional | India > i3 | | MAC-TC-6 | Login - invalid password | v2 | Failed | john | firefox | Regression | - | Columns: Test Case Key (entityKey) | Test Case Summary (summary) | Executed Version (latestVersion) | Execution Status (runStatus) | then one column per UDF label. Use the UDF 'label' as column header. Show null UDF values as '-'.

2. Fetch Test Run UDF values for all executions in test suite run '728995'

{
  "tsrunID": "728995",
  "viewId": 79451,
  "start": 0,
  "page": 1,
  "limit": 20
}

Expected Output: Present as ONE unified table combining identification fields and UDF values — never a separate type+value breakdown. Example: | Test Case Key | Test Case Summary | Executed Version | Execution Status | Tested By | Environments UDF | Planned Execution Date | Execution Type | | MAC-TC-5 | Login test | v1 | Passed | varis | chrome, edge, safari | - | Functional | HTML is stripped from LARGETEXT UDF fields. Null values shown as '-'.

3. Filter by Test Run UDF list/dropdown field (single-select or multi-select lookup) — runs where UDF '8260LUP' has list item IDs 5108701 or 5108697

{
  "tsrunID": "728995",
  "viewId": 79451,
  "tcrUdfFilter": "[{\"type\":\"list\",\"value\":[5108701,5108697],\"field\":\"8260LUP\"}]"
}

Expected Output: Filtered test case runs matching the lookup list UDF values

4. Filter by Test Run UDF multi-lookup list field — runs where multi-select UDF 'PGTE_MULTILOOKUPLIST' contains list item IDs 5126503 or 5126502

{
  "tsrunID": "728995",
  "viewId": 79451,
  "tcrUdfFilter": "[{\"type\":\"list\",\"value\":[5126503,5126502],\"field\":\"PGTE_MULTILOOKUPLIST\"}]"
}

Expected Output: Filtered test case runs where multi-lookup UDF matches any of the given list item IDs

5. Filter by Test Run UDF cascading dropdown field — runs where cascading UDF 'cascade_vK' has list item IDs 5126498 or 5126499 (must set isCascading:true)

{
  "tsrunID": "728995",
  "viewId": 79451,
  "tcrUdfFilter": "[{\"type\":\"list\",\"value\":[5126498,5126499],\"field\":\"cascade_vK\",\"isCascading\":true}]"
}

Expected Output: Filtered test case runs matching the cascading dropdown UDF values

6. Filter by Test Run UDF short text field — runs where text UDF 'TRString' contains the value 'str'

{
  "tsrunID": "728995",
  "viewId": 79451,
  "tcrUdfFilter": "[{\"type\":\"string\",\"field\":\"TRString\",\"value\":\"str\"}]"
}

Expected Output: Filtered test case runs where short text UDF matches the search string

7. Filter by Test Run UDF large text field — runs where large text UDF 'vk_large_text' contains 'this is large text'

{
  "tsrunID": "728995",
  "viewId": 79451,
  "tcrUdfFilter": "[{\"type\":\"string\",\"field\":\"vk_large_text\",\"value\":\"this is large text\"}]"
}

Expected Output: Filtered test case runs where large text UDF matches the search string

8. Filter by Test Run UDF date field — runs where date UDF 'PGTE_DATEPICKER' is after a specific date (comparison: gt) and before another date (comparison: lt)

{
  "tsrunID": "728995",
  "viewId": 79451,
  "tcrUdfFilter": "[{\"type\":\"date\",\"field\":\"PGTE_DATEPICKER\",\"comparison\":\"gt\",\"value\":\"06-01-2026\"},{\"type\":\"date\",\"field\":\"PGTE_DATEPICKER\",\"comparison\":\"lt\",\"value\":\"06-30-2026\"}]"
}

Expected Output: Filtered test case runs where date UDF falls within the specified range

9. Filter by Test Run UDF numeric field — runs where numeric UDF 'NB_number_TR' equals 2

{
  "tsrunID": "728995",
  "viewId": 79451,
  "tcrUdfFilter": "[{\"type\":\"numeric\",\"value\":2,\"field\":\"NB_number_TR\"}]"
}

Expected Output: Filtered test case runs where numeric UDF equals the specified value

10. Combine multiple Test Run UDF filters — filter by list UDF AND string UDF AND numeric UDF simultaneously

{
  "tsrunID": "728995",
  "viewId": 79451,
  "start": 0,
  "page": 1,
  "limit": 20,
  "tcrUdfFilter": "[{\"type\":\"list\",\"value\":[5108701,5108697],\"field\":\"8260LUP\"},{\"type\":\"string\",\"field\":\"TRString\",\"value\":\"str\"},{\"type\":\"numeric\",\"value\":2,\"field\":\"NB_number_TR\"}]"
}

Expected Output: Test case runs matching ALL specified UDF filter conditions (AND logic)

11. Full filter combination — standard field filter + Test Run UDF filter + show only runs with defects

{
  "tsrunID": "728995",
  "viewId": 79451,
  "start": 0,
  "page": 1,
  "limit": 20,
  "filter": "[]",
  "udfFilter": "[]",
  "tcrUdfFilter": "[{\"type\":\"list\",\"value\":[5108701,5108697],\"field\":\"8260LUP\"},{\"type\":\"string\",\"field\":\"TRString\",\"value\":\"str\"},{\"type\":\"string\",\"field\":\"vk_large_text\",\"value\":\"this is large text\"},{\"type\":\"date\",\"field\":\"PGTE_DATEPICKER\",\"comparison\":\"gt\",\"value\":\"\"},{\"type\":\"date\",\"field\":\"PGTE_DATEPICKER\",\"comparison\":\"lt\",\"value\":\"\"},{\"type\":\"list\",\"value\":[5126503,5126502],\"field\":\"PGTE_MULTILOOKUPLIST\"},{\"type\":\"list\",\"value\":[5126498,5126499],\"field\":\"cascade_vK\",\"isCascading\":true},{\"type\":\"numeric\",\"value\":2,\"field\":\"NB_number_TR\"}]",
  "showTcWithDefects": false
}

Expected Output: Test case runs filtered by all 7 UDF field type conditions simultaneously

12. Get paginated test case runs with standard runStatus filter

{
  "tsrunID": "2362144",
  "viewId": 104123,
  "start": 0,
  "page": 1,
  "limit": 25,
  "filter": "[{\"type\":\"string\",\"value\":\"Failed\",\"field\":\"runStatus\"}]"
}

Expected Output: Paginated list of Failed test case runs with 25 items per page including testRunUdfs

13. Show only test case runs with linked defects, filtered by Test Run UDF list value

{
  "tsrunID": "107021",
  "viewId": 6887,
  "showTcWithDefects": true,
  "tcrUdfFilter": "[{\"type\":\"list\",\"value\":[5108701],\"field\":\"8260LUP\"}]"
}

Expected Output: Test case runs with defects where the specified Test Run UDF matches

Hints: 1. === MANDATORY RESPONSE FORMAT — READ THIS BEFORE RENDERING ANY OUTPUT === 2. 3. PIVOT RULE — CRITICAL: 4. The 'testRunUdfs' field on each row is a key-value map (object) of UDF field keys to their values. 5. You MUST pivot this into TABLE COLUMNS — do NOT render it as rows. 6. → Each key in testRunUdfs = use the UDF human-readable label as the column header 7. → Each value in testRunUdfs = the cell value for that run's row 8. → 'fieldType' / 'fieldID' = INTERNAL METADATA — NEVER show these as columns 9. 10. FORBIDDEN PATTERNS — NEVER do any of these: 11. ❌ Do NOT render a separate sub-table (Label | Type | Value) per tcRunID 12. ❌ Do NOT show 'Type' or 'fieldType' as a visible column 13. ❌ Do NOT group output by tcRunID with individual breakdowns beneath each 14. ❌ Do NOT show raw UDF field keys (e.g. 'TRString', '8260LUP') as column headers — use human-readable labels 15. 16. REQUIRED OUTPUT — ONE unified table, all runs as rows: 17. | Test Case Key | Test Case Summary | Executed Version | Execution Status | <UDF Label 1> | <UDF Label 2> | ... | 18. |---------------|-------------------|------------------|------------------|---------------|---------------|-----| 19. | VKMCP-TC-1 | Login test | v1 | Not Run | varis | chrome, edge | ... | 20. | VKMCP-TC-2 | Invalid password | v2 | Not Run | john | firefox | ... | 21. 22. MANDATORY COLUMNS (always first, in this order): 23. 1. Test Case Key → entityKey (e.g. 'VKMCP-TC-1') 24. 2. Test Case Summary → summary (test case name) 25. 3. Executed Version → latestVersion (e.g. 'v1', 'v2') 26. 4. Execution Status → runStatus (e.g. 'Not Run', 'Passed', 'Failed') 27. 5. Tested By → testedBy/executedBy when present 28. 6+. One column per UDF field — use the human-readable label as header, the value as the cell. 29. 30. Null UDF values → show as '-' in the cell. 31. If testRunUdfs is empty or hasTcRunUdf is false, still show columns 1-5. 32. CHAINING WITH FETCH TEST RUN UDF VALUES: 33. If the user explicitly asks for Test Run UDFs with these test case runs, call 'Fetch Test Run UDF Values' after this tool with sourceContext='testSuiteRun' and sourceRows=. Render that tool's unifiedTableRows as the final answer. 34. === END MANDATORY RESPONSE FORMAT === 35. 36. CRITICAL WORKFLOW FOR FETCHING ALL EXECUTIONS OF A TEST SUITE: 37. When user asks to: 38. - 'fetch all executions' 39. - 'get all test runs' 40. - 'fetch all tcRunIDs for test suite X' 41. - 'update status for all executions of test suite X' 42. STEP 1: First call FETCH_EXECUTIONS_BY_TESTSUITE tool with the test suite ID (tsID, not entityKey) 43. - This returns ALL execution records for that test suite (could be 3, 5, 9, or any number) 44. - Extract ALL tsRunID values from the response data array 45. - Example response: data: [{tsRunID: '2739237', ...}, {tsRunID: '2739236', ...}, {tsRunID: '2739235', ...}] 46. STEP 2: For EACH tsRunID from Step 1, call this tool (FETCH_TEST_CASE_RUNS_BY_TESTSUITE_RUN) 47. - This returns all test case runs (tcRunID values) for that specific execution 48. - Repeat for ALL tsRunID values discovered in Step 1 49. STEP 3: Collect all tcRunID values from all executions 50. - Now you have the complete list of test case runs across ALL executions 51. - Use these for bulk status updates or other operations 52. CRITICAL ERROR TO AVOID: 53. - NEVER assume or hard-code only 2-3 execution IDs 54. - NEVER skip Step 1 - always discover ALL executions first 55. - NEVER fetch tcRunIDs for only some executions - get ALL of them 56. - If there are 9 executions, you must fetch tcRunIDs for all 9, not just 2 57. EXAMPLE WORKFLOW: 58. User: 'Fetch all test case runs for test suite VKMCP-TS-21' 59. Step 1: Call FETCH_EXECUTIONS_BY_TESTSUITE with tsID (resolved from VKMCP-TS-21) 60. Result: Found 9 executions with tsRunIDs: 2739237, 2739236, 2739235, 2739234, 2739233, 2739232, 2739231, 2739230, 2739229 61. Step 2: Call this tool 9 times (once for each tsRunID) 62. Call 1: tsrunID='2739237' -> returns 54 tcRunIDs 63. Call 2: tsrunID='2739236' -> returns 54 tcRunIDs 64. ... (repeat for all 9) 65. Step 3: Total collected: 9 executions × 54 test cases = 486 total tcRunIDs 66. 67. PERFORMANCE CONSIDERATIONS FOR LARGE TEST RUNS: 68. When dealing with large numbers of test case runs (500+, 1000+), follow these guidelines: 69. 1. ALWAYS inform the user about the scale BEFORE starting operations: 70. Example: 'Found 9 executions with approximately 486 test case runs. This will require fetching data from all 9 executions and may take a moment.' 71. 2. For bulk status updates on 1000+ test case runs: 72. - NEVER attempt to update all 1000+ in a single operation 73. - Break into smaller batches of 10-20 test case runs per update 74. - Inform user: 'Found 1000 test case runs. Will process in batches of 20 to ensure reliability and performance.' 75. - Show progress: 'Processing batch 1/50 (20 test runs)...', 'Batch 2/50...' 76. 3. Recommended batch sizes: 77. - For status updates: 10-20 test case runs per batch 78. - For fetching data: Can handle larger batches (50-100) 79. - Adjust based on API response times and timeout limits 80. 4. Always provide progress updates for long-running operations: 81. - Before: 'Processing 1000 test runs in 50 batches of 20...' 82. - During: 'Completed 200/1000 test runs (10 batches)...' 83. - After: 'Successfully updated all 1000 test case runs.' 84. 5. Error handling for batch operations: 85. - If a batch fails, report which batch and continue with remaining 86. - Provide summary at the end: 'Completed 48/50 batches. 2 batches failed (batch 23, 45).' 87. - Allow user to retry failed batches specifically 88. EXAMPLE LARGE-SCALE WORKFLOW: 89. User: 'Update status to Failed for all test runs in VKMCP-TS-21' 90. Step 1: Discover all executions (9 found) 91. Step 2: Fetch all tcRunIDs (486 total) 92. Step 3: Inform user: 'Found 486 test case runs across 9 executions. Will update in 25 batches of 20 runs each.' 93. Step 4: Process in batches with progress updates 94. Step 5: Report completion: 'Successfully updated all 486 test case runs to Failed status.' 95. 96. CRITICAL: tsrunID and viewId parameters are REQUIRED 97. tsrunID is a STRING identifier for the test suite run execution 98. viewId is a NUMERIC identifier for the test execution view 99. !MOST IMPORTANT HOW TO GET tsrunID: 100. 1. Call API 'Execution/Fetch Executions' (FETCH_EXECUTIONS_BY_TESTSUITE) to get ALL available executions 101. 2. From the response, get value of following attribute -> data[].tsRunID for EVERY execution 102. 3. Example: Test Suite might have multiple executions with IDs '107021', '107022', '107023', etc. 103. 4. NEVER assume there are only 2-3 executions - always fetch to discover the actual count 104. !MOST IMPORTANT HOW TO GET viewId: 105. CRITICAL: Always resolve and use the correct test execution viewId for the current project when calling this tool. 106. The viewId parameter must be fetched from the active project's info (latestViews.TE.viewId). 107. Each QMetry project may have a different test execution viewId, so using a stale or incorrect viewId will result in incomplete or invalid test case run data. 108. Usage workflow: 109. 1. Fetch project info for the current project (Admin/Get info Service). 110. 2. Extract latestViews.TE.viewId from the response. 111. 3. Use this viewId in the Fetch Test Case Runs by Test Suite Run API call. 112. Example: 113. { 114. tsrunID: "2362144", 115. viewId: 104123, 116. start: 0, 117. page: 1, 118. limit: 25 119. } 120. This ensures the tool fetches the proper execution runs data for the selected project context. 121. SUPPORTED PARAMETERS: start, page, limit, tsrunID, viewId, filter, udfFilter, tcrUdfFilter, showTcWithDefects 122. PAGINATION: Use start, page, and limit for result pagination 123. PAYLOAD FORMAT: {"start": 0, "page": 1, "limit": 10, "tsrunID": "2362144", "viewId": 104123} 124. 125. === TEST RUN UDF (tcrUdfFilter) — ALL 7 FIELD TYPE FORMATS === 126. tcrUdfFilter filters test case RUNS by Test Run UDF values (not test case UDFs — use udfFilter for those). 127. Value is a JSON array string. Multiple conditions are combined with AND logic. 128. Base structure: {"type":"", "field":"", "value": [,"comparison":"..."] [,"isCascading":true]} 129. 130. --- TYPE 1: list (single-select lookup / dropdown) --- 131. Use for: single-select lookup list UDF fields (one value selected from a list). 132. value: array of numeric list item IDs — get IDs from FETCH_CUSTOM_LIST_ITEMS tool. 133. Format: {"type":"list", "field":"", "value":[,]} 134. Example: [{"type":"list","value":[5108701,5108697],"field":"8260LUP"}] 135. Matches runs where the UDF value is ANY of the provided list item IDs (OR within the array). 136. 137. --- TYPE 2: list (multi-select lookup list) --- 138. Use for: multi-select lookup list UDF fields (multiple values can be selected). 139. Syntax identical to single-select list — same format, just the UDF field itself is multi-select. 140. Format: {"type":"list", "field":"", "value":[,]} 141. Example: [{"type":"list","value":[5126503,5126502],"field":"PGTE_MULTILOOKUPLIST"}] 142. Matches runs where ANY of the UDF's selected values match any of the provided IDs. 143. 144. --- TYPE 3: list (cascading dropdown) --- 145. Use for: cascading dropdown UDF fields (parent-child linked dropdowns). MUST add isCascading:true. 146. Format: {"type":"list", "field":"", "value":[,], "isCascading":true} 147. Example: [{"type":"list","value":[5126498,5126499],"field":"cascade_vK","isCascading":true}] 148. CRITICAL: missing isCascading:true on a cascading field will cause incorrect results or API error. 149. 150. --- TYPE 4: string (short text) --- 151. Use for: single-line text UDF fields. 152. value: the string to search for (partial match / contains). 153. Format: {"type":"string", "field":"", "value":""} 154. Example: [{"type":"string","field":"TRString","value":"str"}] 155. 156. --- TYPE 5: string (large text / rich text) --- 157. Use for: multi-line or rich text UDF fields. Syntax is identical to short text string type. 158. Format: {"type":"string", "field":"", "value":""} 159. Example: [{"type":"string","field":"vk_large_text","value":"this is large text"}] 160. NOTE: Search is against the raw (HTML) content stored in the field; plain text search terms work fine. 161. 162. --- TYPE 6: date --- 163. Use for: date picker UDF fields. REQUIRES a 'comparison' property. 164. comparison: 'gt' = after the date (greater than), 'lt' = before the date (less than). 165. value: date string in 'MM-DD-YYYY' format, or empty string '' to leave the bound open. 166. Format: {"type":"date", "field":"", "comparison":"gt"|"lt", "value":"MM-DD-YYYY"} 167. Example — date range: [{"type":"date","field":"PGTE_DATEPICKER","comparison":"gt","value":"06-01-2026"},{"type":"date","field":"PGTE_DATEPICKER","comparison":"lt","value":"06-30-2026"}] 168. Example — open-ended (no upper bound): [{"type":"date","field":"PGTE_DATEPICKER","comparison":"gt","value":"06-01-2026"}] 169. To filter by a single date use two conditions (gt day-before AND lt day-after) or just one bound. 170. CRITICAL: 'comparison' field is mandatory for date type — omitting it causes API error. 171. 172. --- TYPE 7: numeric --- 173. Use for: number UDF fields. 174. value: a number (integer or decimal). 175. Format: {"type":"numeric", "field":"", "value":} 176. Example: [{"type":"numeric","value":2,"field":"NB_number_TR"}] 177. 178. --- COMBINING MULTIPLE FILTERS --- 179. All conditions in tcrUdfFilter array use AND logic — runs must satisfy ALL conditions. 180. Full example (all 7 types combined): 181. [ 182. {"type":"list","value":[5108701,5108697],"field":"8260LUP"}, 183. {"type":"list","value":[5126503,5126502],"field":"PGTE_MULTILOOKUPLIST"}, 184. {"type":"list","value":[5126498,5126499],"field":"cascade_vK","isCascading":true}, 185. {"type":"string","field":"TRString","value":"str"}, 186. {"type":"string","field":"vk_large_text","value":"large text"}, 187. {"type":"date","field":"PGTE_DATEPICKER","comparison":"gt","value":"06-01-2026"}, 188. {"type":"date","field":"PGTE_DATEPICKER","comparison":"lt","value":"06-30-2026"}, 189. {"type":"numeric","value":2,"field":"NB_number_TR"} 190. ] 191. --- FILTER PARAMETER SUMMARY --- 192. tcrUdfFilter: filter by Test Run UDF fields (this section) 193. udfFilter: filter by Test Case UDF fields (different from test run UDFs) 194. filter: filter by standard execution fields (runStatus, executedBy, etc.) 195. All three can be combined in a single request — they are independently applied with AND logic. 196. 197. hasTcRunUdf FLAG — IMPORTANT: 198. The response contains a 'hasTcRunUdf' boolean flag at the top level. 199. hasTcRunUdf: true → Project has Test Run UDFs configured; each record includes 'testRunUdfs' object. 200. hasTcRunUdf: false → Project has NO Test Run UDFs configured. 201. When hasTcRunUdf is false, the response includes a 'testRunUdfNote' with a professional explanation. 202. Inform the user: 'No Test Run UDFs are configured for this project. Contact a project administrator to set up Test Run UDF fields.' 203. NEVER attempt to read testRunUdfs from records when hasTcRunUdf is false — the field will not be present. 204. 205. TEST RUN UDF RESPONSE (testRunUdfs): 206. When the API returns Test Run UDF data, each row will include a 'testRunUdfs' object. 207. This is a key-value map of UDF field keys to their values, parsed from the API's 'udfjson' field. 208. HTML is stripped from rich text (large text) UDF fields for readable LLM output. 209. Example testRunUdfs in response: 210. testRunUdfs: { 211. "8260LUP": "l1", 212. "look_554": "99", 213. "cascade_vK": {"child": "aa", "parent": "abc"}, 214. "dateNJ": "06-02-2026", 215. "NB_Multilppup_TR": ["ahd"], 216. "Jal_Largetext": "asdef asdfads asdfasf asdf asdf asfd a sdfa" 217. } 218. Use pagination for large result sets (start, page, limit parameters) 219. This tool is essential for detailed test execution analysis and reporting 220. Critical for monitoring individual test case execution performance and UDF values 221. Use for compliance reporting and execution audit trails 222. Essential for test execution quality assurance and trend analysis