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

Discussion

Discussion

Records Management Activities in Workflow

posted on July 10, 2020

Has anyone else run into an issue when promoting Workflows from one environment to another? Records Management Activities almost always break, for example, in a current workflow, we assign a file date, cutoff instruction, event date, and finally a retention schedule. Each of these is set based on a conditional which evaluates which set of these variables each document should receive. For example a document may go down a branch that has the event based cutoff instructions set as the expiration date of the document. 

When transferring these Retention objects from one admin console to another and importing the workflow, all of the cutoff instructions are switched to another cutoff instruction. So, Termination date event activity may now be in the Expiration date path and vice versa. The fix is of course to go through each cutoff instruction activity and set it back to the correct instruction.

In my most recent migration to a production environment, I now am running into an issue where workflow is attempting to set the termination event date and it is terminating the workflow and telling me "One or more of the selected events are not valid for this records management object. [9116]" The fix for this is to delete the event from the workflow activity and re-add it. 

Obviously there are some bugs when it comes to migrating workflows with RME activities. I am wondering if anyone else has experienced these issues and if Laserfiche knows about this.

- Justin

1 0
replied on July 14, 2020 Show version history

Hi Justin,

I'm sorry to hear you've run into this frustrating promotion issue with Workflow RM activities. Thank you for sharing the details.

The root cause here is that Workflow definitions represent RM objects by their ID#s rather than their names. If you crack open a Workflow XML you'll see something like "Cutoff_ID = 6" instead of "Cutoff_Name = '3 years'". Migrating the RM objects between repositories in the Admin Console does not actually preserve the object IDs; new IDs are assigned on import. As a result these IDs are (generally) not consistent across environments/repositories.

Because "Cutoff_ID = 6" references different (or non-existent) Cutoff instructions in the different environments, you're seeing them switch (or be marked invalid) in the Workflow on promotion. When you drop and re-add the RM activity, it sets the object ID reference correctly for the current repository. For the moment, your best course of action is planning to check and update Workflow RM activities as part of your promotion process.

I've passed this post to the Workflow team to make sure they're aware.

 

Best,

Sam

1 0
replied on July 15, 2020

Interesting, thank you for sharing!

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

Sign in to reply to this post.