Hi Navsta,
What worked for me was to use the folder structure to file Test Cases into a logical order to make it easier to locate the TCs when required. An example of the folder structure I used, is: "Test Phase + Test Team" > Product > Function. Including the Test Phase and Test Team at the top level was useful to easily store test cases that were being used in a specific test stage (e.g. SIT E2E), and which test team (internal, vendor, partners) were responsible for its execution. The labels feature in a Test Case enables a further way of logically grouping tests and you may find that useful too.
After the Test Cases were created, I then setup a hierarchy of Test Plan(s) with Test Cycles, where the Test Cycles once again include the testing team + the name/function/product. I found this approach was useful for reporting and using the Test Cycles page as a dashboard (this is an excellent page for an overview of testing progress).
In scenarios where the same Test Cases were to be executed multiple times, e.g. for different browser platforms, I preferred to add those test cases into separate Test Cycles, using the Test Cycle name (and adding the platform) as a way to logically group tests. For example: the Test Cycle Names might be "SIT-E2E Test Function A on Edge", "SIT-E2E Test Function A on Chrome", "SIT-E2E Test Function A on Firefox". The main reason I use this approach is to make dashboarding and reporting easier.
Hope that helps.
Andy