Solution Workbench Improvements (Suggestions)

So this little feature is used by all of us, but at least thus far has been largely ignored from the rich new features that Epicor has been working on.
I figured it would be nice to throw out here a post with suggestions on how to improve Solution Workbench to better serve us all, specially since we use it more than anyone else.
Here’s my current list of Fixes / Suggestions

  1. Improve Search
    Currently in solution workbench there is 1 “Generic” search adapter that is used for all Element Types, this means that the search is helpful for none of them. There is no technical reason why we shouldn’t be able to invoke the default adapter search for each of the given elements which have one.
    For example when searching for Method Directives, bring up the well known Method Directive Search from Method Directive Entry, when searching BAQ’s bring in the BAQ Entry Search and for Customizations bring up the Cutomization Maintenance search.
    These search screens generally provide the right information / display to let you more easily pick what is you want to include in your solution.
    The current system is too generic and sometimes it takes quite a bit of effort to pick the right BAQ or BPM using the search

  2. When a solution is exported, export IT along (as an option)
    When you export a solution from solution workbench you should have the option to include the solution itself. Right now it exports the components, but the solution definition is left behind. This can be inconvenient because sometimes we go and move a solution from System A to System B and then make changes in System B then we want to be able to once again export that solution and have to re-create it.

  3. Include extended properties specifically as an exportable element in the solution workbench
    Changing extended properties in standard and UD fields is pretty common and there is no way to grab just those changes in solution workbench. It would be great to be able to grab these.

  4. I’m sure this is already coming, but include Epicor Functions as exportable in solution workbench

  5. Highlight changes after items have been added to the solution workbench.
    If an item is changed after it has been added to solution workbench highlight it (yellow, or something) in the selection grid. Reset this once the solution has been exported

  6. For solution tracking allow us to specifically exclude certain business objects (Report monitor) from tracking

I have no idea if Epicor will or will not read these (they read EVERYTHING… right @Bart_Elia!) , but I can guarantee you they won’t if it doesn’t exist, so please pile on (CONSTRUCTIVELY) and let us hope we can get their attention.

What he said…

When you export a Report Style, it asks to you to include a .rdl – however unlike the Report Style Maintenance it doesnt include the “Sub-Reports”. So when you want to export JobTrav for example, you can’t use Solution Workbench.



The search screen especially for menu items is a chore. I usually sort by the -c arguments to find what I need.


Yes! while(1) this++;

1 Like

Yes this is great enhancements! :+1::+1::+1::+1::+1:

We do - thanks for outlining thoughts we can do much better in this area.


It now includes the RDLs properly! Atleast In 10.2 I noticed it, thank you!!!

@Edge I do agree with @josecgomez Extended Props Comment above

I tried to Export them even using Adapter etc… Didnt work, I had to instruct our IT team to do Paste/Update by providing them Excel Sheet for Extended Props Maintenance Screen.


I’m not sure we could achieve this in a meaningful way, but lets thinking through what we have today, what you mean? and how we might do it. I will say we can give you a basic and fairly unreliable way of doing so based on some flawed assumption that will work 60-70% of the time but could lead you very far astray in other edge cases.

My apologies ahead of time, this is very stream of consciousness and I am wordy. I’m not trying to nix doing this, just want to make sure we understand what is being asked for and you all understand the potential limitations of what you are asking.

Today we keep track of 2 pieces of data: The SysRowID of the DB record to be included and the Schema.Table name of the table that holds the data. We do not know anything specific about that table or data.

At its most basic we would simply:

  1. Add a ForeignSysRevId column to the SolutionDetail table and it would start empty
  2. This means that before a solution is ever built, it will always be yellow
  3. Then when a solution is built and we go and grab the record, we will also grab the value of the SysRevID and set it as well.
  4. now later either all the time or when a ‘check is made to find status’ We can run through the definition and flag all items whose related row has a different sysrevid as yellow or different.

So this part makes sense and looks cool, now let’s add complexities:

What if someone has done a few ‘test solutions’ that were never installed. Is that what you want? It won’t be compared ot whats on you live server or any server, just compared to the last time ANYONE built it.

What if a record was reimported or restored between solutions built- that would change the sysRevID but the ‘new one’ is an ‘old one’ we do not have a way of making that distinction to warn you.

SysRevid is environment specific. Move the solution to another environment you have a different SysRevId there. We can reset the SysRevID values during import but now the solution definition in system A has a completely different set of SysRevIDs as the solution definition in System B - is this going to create a logic issue confusion depending on where you look? We now have 2 definitions of a solution - which is the master? Against which one was that solution package you have build against?

What about items that are removed from the definition after the last build? Do we care about those?

What are we trying to achieve? I think what we are trying to achieve is to answer a basic question: do I need to make a new version of my solution package or not? We could instead try to answer that by carrying the sysrevID value into the solution package and then compare it to what is in the current system. That would also spot gaps of items in the solution that are not in the definition or even the system as well. But what does that mean? do you know what DB you built the solution against because otherwise everything will always be yellow.

This seems to be a desire to have source control patterns with solutions. But that requires a single source of truth, and intercept and control over all record additions and edits in general not just solution definitions. By the vary nature of how ERP databases are copied, restored and moved from Pilot to test to live, to dev and back again I am not sure there is a general way to achieve single point of truth and without some fundamental structure changes to the ERP system as a whole we do not have the intercept point and logic to apply versioning logic to the data in the system.

Given all this would you:

  1. want to drop it from the list?
  2. Accept the cheap version that is very unreliable without self enforced context specific rules about when/where/how solutions are packaged?
  3. Invest very heavily into adding Source control patterns to general ERP configuration and setup data to allow for source control processes.
1 Like

For this item you can achieve this today in solution workbench - know for any version of 10.2 but likley for any version of 10.1 as well using solution types and elements. it is an area many have not played with and it may not be what you are looking for, but here is link to a 5 minute video explaining. Apologies for spur of the moment videos that could be 2 minutes shorter and far more professional - but hey its free :slight_smile:

BTW I make no guarantee’s I’ll leave this available forever. Eventually I’ll want my drive space back.

1 Like

This would be a big improvement. I really don’t like that feature or lack of.

Wow @pferrington Thanks for the reply!

So obviously pie in the sky is option 3, but I get that’s likely unrealistic. As cool as you and I and a handful of others would think of that, the Marketing Dollars of that feature would probably not go far. So I’ll say 3 if it can happen, but I’m not holding my breath.

I think the “cheap” version is better than nothing it serves to give the user a “heads up” something changed. They may not know exactly what changed or who did it, but it could provide just a simple gut check or an early warning system that something may be off.

Thanks again!

1 Like

In 10.2.400.10 atleast there is a bug when I select “Prompt for Overwrite” and I deploy a new Dashboard (BAQ, Dashboard, Security, Menu) it says “Error in the application” but deploys fine. If I use the “Automatically overwrite” radio button, no error.

I traced it and when you do prompt for overwrite, it does a few extra GetByIDs to see if element exists, in order to prompt you, and it thinks that one of them is an “Error”.

Just heads-up.