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

Question

Question

where does the forms instance column title come from?

asked on June 20, 2019

I have a cancel leave path that is dropping some variables.

Path 1 is taken when the initiator selects Cancel Previously Approved Leave from a select list.

Path 2 is taken when the leave submitted has not been approved and the initiator is able to go into their inbox and take action on the form and cancel the leave.  

Path 3 is the routine path for approvals...

So all paths hold the Instance name with Variables but the First.  The formatting of the Subject line doesn't matche the Repository naming convention we have set so I'm not sure...   So where is path 1 getting the Instance name from?

 

{/dataset/Leave_Type_} {/dataset/_initiator_displayname} {/dataset/start_date_time} - {/dataset/end_date_time}

Annual (LANL) - Suzanne J. Anglim - 4/13/2019 3:14:52 PM to 4/13/2019 3:14:52 PM

 

 

Thanks bunches :)

0 0

Answer

SELECTED ANSWER
replied on June 20, 2019 Show version history

You would put the "Throw" inline wherever you want it to stop the process, and you would attach a signal event listening for that signal to any tasks that you want ended by that action.

A couple limitations with signals:

  1. A separate submission cannot directly cancel tasks in a different instance
  2. Signals can only interrupt User Tasks

I can't guarantee that signals will give you what you want, but it seems like they would and, in my opinion, terminate end events should be a last resort.

0 0

Replies

replied on June 20, 2019

Instance Name is configured in Settings > Process Options from the forms designer.

On a side note, are you sure you want to use "Terminate End Events" instead of regular end events? That will cause those instances to show up as "Terminated" instead of "Completed" in the history.

0 0
replied on June 20, 2019

Thanks Jason for the response!!!  I knew I've seen it somewhere...   Got it!

I have had lengthy discussions with vendor on this.  And he said for this particular workflow we would need to use them.  The idea is I want the initiator to be able to Cancel the leave request from a task in their inbox UNLESS there is final approval taken.  Then the initiator will have to submit a new form and select the Cancel Leave radio button (the other being "Submit New Leave").  Once the Cancel is selected a drop down list will display APPROVED leave for the last 2 weeks.  They would select and I have a workflow kicking off and updating the metadata on the file in the repo and notifying Time Keepers that they need to take action on it.

IF I do not terminate... then if the Approver approves before the initiator Cancels then the initiator Cancel path (2) stays active.  Terminating kills all paths.  And visa versa... IF the initiator Cancels, the Approver task is still active.  I tried as many ways as I could think of before contacting vendor support.

In the history it is actually showing Completed via terminate end event.

Thanks again for your response!!

0 0
replied on June 20, 2019 Show version history

Maybe the vendor knows something about this process that I don't, but this sounds like exactly the kind of situation Signal Events are designed for.

Here's what you do:

  1. Add a Signal Throw event after the tasks
    1. Under "broad cast signal" create a signal called "Cancel"
  2. Attach a Signal Event directly to the tasks you want cancelled 
    1. Set it to listen for the "Cancel" signal
    2. Set it to "interrupt" the attached event
    3. Attach the signal to an end event

Basically, you just set it so that once certain paths are hit, it fires the signal event that will interrupt any pending tasks listening for that signal.

If the only reason for the Terminate End Event is that you want to "end" any other active tasks, then Signals will work in most cases.

Obviously your process is more complex, but the example below demonstrates the general concept. Both tasks are assigned in parallel and remain active, but, if either one is submitted, it throws the signal and ends the other one.

0 0
replied on June 20, 2019

Hmmmm  I will try first thing Monday.  I did have a throw/catch event on there and he said I didn't need...  There can be up to 4 approvers... so between the arrows it repeats 3 more times...  Would I put at the green arrows?  Or on the same repo and email initiator??

 

 

Great discussion on throw/catch!!  THANKS!!  WE are working 10 x4 days so off tomorrow.  will try everything Monday!!

0 0
SELECTED ANSWER
replied on June 20, 2019 Show version history

You would put the "Throw" inline wherever you want it to stop the process, and you would attach a signal event listening for that signal to any tasks that you want ended by that action.

A couple limitations with signals:

  1. A separate submission cannot directly cancel tasks in a different instance
  2. Signals can only interrupt User Tasks

I can't guarantee that signals will give you what you want, but it seems like they would and, in my opinion, terminate end events should be a last resort.

0 0
replied on June 24, 2019

Guess what?!?!?!  It worked!!  You rock Jason.   Thank you so very much.  I will let the support guy know too smiley

 

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

Sign in to reply to this post.