You are viewing limited content. For full access, please sign in.

Question

Question

Workflow Brainstorming

asked on June 25, 2015

Hello!

I've got a fairly interesting challenge for a workflow I'm rewriting from V7 and I thought it could benefit from brainstorming ideas from the community.

I have some incoming documents which must be filed by a numeric code in a field.  

The filing happens for ranges of numbers in that code. 

For example, any doc with a code between 1000 and 1200 goes to department A.  1200 to 1305 goes to department B. 

The assignments are fairly arbitrary.  For the v7 workflow these were configured individually.  There must be a better way!  : )

 

So, what would you do?  Incoming documents should be split depending on the range of their assigned code (from a field.)

 

So far, I'm thinking some sort of look up table.  I'd have to figure out how to implement that first...

 

Thanks!

MIke

0 0

Replies

replied on June 26, 2015
 
 

Hi Michael,

 

I don't know if I have much value to add to your thinking but maybe this reaffirms your view. Here's how I thought about it.

 

It would depend on how many code ranges there were. If the ranges were around 10, I'd probably hand code them like this. (Which is what it sounds like you're doing now.)

 

 

Even at 10 branches, I'd probably make a conditional send anything below code range 2000 to the left branch for further evaluation and everything above to the right for further assignment.

 

The look-up table option works but it's another piece of the solution to manage over it's life cycle. The more moving parts, the harder it is for someone to manage.

 

Maybe if I made a form or some way to manage this look-up table already to handle the code changes. And the document code ranges change all the time, way more often than the workflow itself, the look-up table is definitely the way to go.

 

For a look-up table you could go as simple as an access database on the workflow server. Anywhere a connection can be made from workflow and whatever you are using to maintain it is good.

 

 
1 0
replied on June 26, 2015

I'd go with putting the branches in the workflow if the definitions of the ranges are not likely to change much. If they're changing more than once a year, then I'd go with a SQL table in the Workflow database itself so you don't have to worry about missing drivers or losing it when you upgrade or change servers. I'd have the departments and the start and end of the ranges as separate columns. The down side is you have to edit the workflow if a new department is added.

Setting up a lookup table would make the workflow super simple if the same type of action is done for all departments since you'd basically be down to 2 activities: Query Data to get the department name and Route to Folder to send it to the department. You could easily update the table from an Excel spreadsheet that SQL automatically imports from a known location on a schedule.

On the other hand, if the data rarely changes, condition evaluation is way faster than connecting to SQL and running a query.

1 0
replied on June 26, 2015

Thanks everyone!

 

The data changes very rarely, but there are many ranges - almost 100.  :)

 

So, do I spend my time building 100 conditionals, or figuring out the SQL query route...  That is the question, I suppose.

 

 

 

0 0
replied on June 26, 2015

The Routing Decision is always faster. If you want to try it out you could make an activity with an impossible condition in the first branch, copy and paste it a few times, then select all these new branches and paste them until you get close to 100. All branches will be evaluated and fail. That would give you the worst possible evaluation scenario because Routing Decision only evaluates conditions until it finds a match, then skips the rest. Run that as well as a Query Data against any SQL table. It should give you an idea of the run time difference between the 2 activities.

 

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.