Join 34,000+ subscribers and receive articles from our blog about software quality, testing, QA and security.

Adding a new test run configuration to an existing entry


Hello Jorge,

Thanks for your posting and feedback on this. We currently don’t have an estimate for this feature request and recommend using a separate test plan entry (per configuration) if you need to dynamically create/delete configurations (add_plan_entry). Adding/deleting test runs/configurations to/from test plan entries is currently only supported via the UI. I’ve just added another vote to the API enhancement request, thanks!



Hello Tobias,

Many thanks for the quick reply! At the moment we are adding the test suites with configuration as SEPARATE entries in the test plan but as you can imagine it is a pain to scroll up and down the test plan to visualize the results (i,e, same test suite running on various configurations).

Anyway, hope this feature will be implemented in Test Rail soon! :slight_smile:

Many Thanks!


Hello Jorge,

Thanks for the update. You can change the view mode for test plans (via the little yellow icons next to the test plan name when you view a test plan). The test runs will then be displayed in a more compact way and require less screen space.



It’s been about a year and a half since this thread was created, and it’s still a badly needed feature. The various multitude of configurations I have makes information unwieldy.

My workaround is to make a new copy of all the existing configurations and test results, and append the new configuration to this copy. Then I delete the old ones. This is awful. Please end my suffering.


Hi there!

Thanks for your feedback. It’s still planned to look into this and I’m happy to add another vote to this feature request. I currently don’t have a time frame or estimate for this feature but API enhancements (especially configurations) are on our todo list.



Yup, this makes using configurations from the API pretty useless unless you know upfront what all configurations you want to test – and that often does not happen when running via an Automated environment.

Is this something that requires much refactoring to implement? Seems like 2 years is a long time to wait for this.


Hi Jim,

Thanks for your feedback. One alternative could be to create runs for all configurations you have, even if you don’t use them but I understand that adding configurations on the fly would be preferred. Instead of using configurations, you could also look into creating plan entries (runs) without configurations (so, one add_plan_entry per automated run). It’s definitely still planned to look into adding support for changing the configuration set also with the API.



After much effort, I have now finished writing a complex system that creates a new test run with data from all previously entered configurations, along with the new one I want to add. It then deletes the original set. Oh, and there’s a locking system in place, to prevent multiple processes from competing with each other.

This is a terrible solution, and it generates a ton of unnecessary traffic to your servers, but it works. This is a hugely important feature to the API, and after spending so much time developing a workaround, I feel justified in bumping this thread.

(Up next: Alphabetizing runs using the same method. That’s going to be an order of magnitude more server calls…)


Thanks for your feedback! A simpler solution would be to add a new and separate test plan entry via add_plan_entry and leave the other test runs as is. Other than all test runs/configurations would appear in the same entry (group of runs inside the plan), there’s no practical difference (you would still have the same set of test runs).

I hope this helps!



Unfortunately, add_plan_entry does not allow modifying an existing run configuration. This does not work for my org’s needs - We have far too many scenarios that would make it too much effort for my testers to easily parse through without a logical grouping like configurations.


How many configurations/configuration combinations/runs do you have in a typical test plan? If you know the configurations you want to use in advance, you can simply specify the full set of configurations via add_plan or add_plan_entry and you wouldn’t need to add plan entries or configurations separately afterwards. If you need to dynamically add test runs/configurations, adding new entries via add_plan_entry would also work well depending on the number of configurations. If you have many configurations, users can also switch the test plan layout to a more compact version (via the yellow icons in the toolbar) and this provides a much cleaner/better overview for large test plans.

I hope this helps!



I see with TestRail 5.2 the following features have been added to the API:
Added: Support for run/configuration description for add_plan/add_plan_entry/update_plan_entry API methods
Added: Support for adding/updating/deleting configurations via the API (add/update/delete_config_group and add/update/delete_config)

If I understand correctly this does not include updating configurations in an existing plan entry. Is this still on the roadmap?



Hello Kurt,

Thanks for your posting. Yes, that’s correct and this would be independent of the configuration/run management inside a plan and is for managing the configurations themselves (so, to add/update/delete configuration groups and configurations).

You could only add/update/delete configurations in the UI previously (in the Select Configurations dialog) add adding the add/update/delete API methods for configurations was one of the missing pieces of the API.

Regarding your other question: yes, it’s still planned to look into extending update_plan_entry to add support for updating configurations and this is still on our list. update_plan_entry already supports some of the features you can configure in the UI (such as updating the case selection if you haven’t overridden the case selection for the configuration), but it’s definitely planned to cover the same feature set with the API in the future.



Updating the configurations applied to an existing Test Plan via the API would be a great addition to the library that my team and I would love to take advantage of with our automated testing. +1


Hi Christopher,

Thanks for your feedback. This is already partially supported and you can add new plan entries (with configurations) or remove plan entries. Updating plan entries (and the runs/configuration in it) is also already supported to some extent and you can change the properties of the plan entries which is then propagated to the runs/configurations if they use the entry-level settings (case selection, assignee).



Please add my vote to this. With automation environment this feature is really mandatory. Without this support, we need to depend on manual intervention

I started the test run with the below config
fw1: abc
driver1: 123

Now i received one more fw when test is going on. So i will pause the test, update the new firmware and will resume the test. When test is resumed, we should have the ability to add ‘fw2: dfg’ to existing test run.


Hi Tobias,

Would it be possible to get an update on this feature request. I notice that this has been outstanding for quite some time now.

Our engineers would like the ability to use the ‘update_plan_entry’ API to add one config id to existing test plan entry/run.

Please see riyyappan’s earlier post on this thread. Our test engineers are finding this issue to be a show stopper.

Could you please provide us with some guidance / updates.



Update_plan_entry API does not allow adding new test cases?
if i want to add more test cases to my Test run with configurations
how can i can them to a specific configuration?
is that supported from the API?


im trying to Manipulate
an individual test run/configurations {want to add more TC’s to a specific configuration}
is it supported already with update_plan_entry API?



Hi roller,

Thank you for posting! The update_plan_entry API does allow you to update the case selection for a test plan entry. However, when using this API method, the case selection would be updated at the plan entry level. The entry-level case selection would apply to all of the configurations within the plan entry as long as the configuration did not have a configuration level case selection. A configuration level case selection overrides the entry level case selection. Therefore, using the update_plan_entry API method would not update the configuration level case selection. It is not possible to update the case selection for an individual configuration within a test plan entry via the TestRail API at the moment. We are happy to review adding support for this in a future update. In the meantime, you can update the case selection for the configurations within a plan entry from the TestRail UI.

I hope this helps!