How do you structure workflow tests

Firstly, the correct thing is the thing that make yourself more efficient, not the other.

Then the choice of structure could depend on which kind of tests you do.

As for me, we use TC for RPA and tests as functiunal acceptance, end-user scenarii, through single or multiple apps (heavy client, light client, web, mobile, mainframe, ...).

We do only script TC.

We have a commun repository for all common libraries (like system.js, services.js, database.js, cmd.js, ....) and all main software engines (like sap.js,  inforM3.js,  sageX3.js, axelor.js, oracleEBS.js, webcheck.js, ....) and all main integration engines (like jira.js, squash.js, testlink.js, redmine.js, ...).

All engines are closure-style object.

After, we have a repository of projects per customer. Each project has one or several test scenario.

For example, a customer in insurance, we have one project (name of the customer) and inside, several projects suites to test rates engine, end-user prints, claims and poilicy workflow, ..

Each project suite use libraries of the common repository and three files for the project suite itelsef; example for rate engine; 

1. rateEngine.js which manage the loop of tests cases read from Excel, its mainly call of customer app engine functions with data  read from the excel
2. rateEngine_context.js which manage start/end test session/case/step  integration with ticketing system and test management software
3. rateEngine_globals which contains some usefule globals

Inside TC we have only 3 test items;

1. Initialization which call startTestSession inside rateEngine_context
2. Excute which call playTest inside rateEngine, this one is called only if initialization has been successful
3. Finalization which call endTestSession inside rateEngine_context

Starting a new customer or a new project suite is made easily because we have a console script that create all pathes and files wanted after answering some questions (name of customer, name of project, include webapps, include which engine, ...).

If customer use only apps we have already in our repositories, it's 75-90% direct reuse, the remaining part is to follow changes in business process of the customer.

If customer use new apps the console script build us the engine for all standard functions and we have to add business process functions only, so a 50% direct reuse at least.