There are couple of standard profiles that you can use, if you were looking at indexing issues, I’d be starting with the index tuning wizard and generating a trace on that. There are a lot of posts around that topic, as always I’d be starting one of the authorities being Brent Ozar and his blog https://www.brentozar.com/ and other indexing tools that are available (Redgate), and of course Microsoft’s own Docs on the Databasase Engine Tuning advisor.
As far as what to return in a standard trace, I’m a bit lazy and I should have a custom template with all the options setup, but I don’t I just start with the TSQL template normally and trim it down, showing all events and filtering by the database name. Not really that scientific an approach, but at the end of the day profiler can be used for all sorts of different investigations, from performance to errors, to security auditing, so it really depends on what you are looking for, as to how you setup the profiler template, but the base templates are a good start. Most importantly remember that you can affect performance if you are running profiler and you can always search the events if you are looking for something specific. (ctrl-F)
While digging around generating my response, and this shows how distracted I’ve been, that in this post they mention Profiler is depreciated https://docs.microsoft.com/en-us/sql/tools/sql-server-profiler/sql-server-profiler?view=sql-server-ver15, basically it mentions you should be using Extended Events instead here’s a link Quickstart: Extended Events in SQL Server - SQL Server | Microsoft Learn. When I get some more time I’ll be reading it myself.
The other thing that was pointed out in another post recently is that the data dictionary (there’s a few)
Improving BAQ Performance - #9 by josecgomez contains a list of all the indexes so it’s easy to see that from within Epicor instead of having to hassle the DBA (if your not it in your business) and run an SP_Help or use SSMS to look at the database details.
Answering your question about the end game of the exercise is to work out exactly which query during the process is causing the issue (CPU time, Reads) then take that query from profiler, load it with the relevant parameters, clear your procedure cache, then take a look at the execution plan of that query. That will help you determine where things are going wrong if it is a SQL issue, it could be poor code, everyone can be guilty of that from time.