Connection Request Manual trigger Workflows do not behave as expected

[stanalyst]

Description

Background: We have a workflow which we want to be able to manually run from both the Person Profile action menu and from Connection Requests. We have the workflow check the incoming Entity Type to know how to get the Person - and the Connection Request when appropriate - then either present a user entry form for confirmation and customization of an email message to send - or a message indicating their request can't continue and why. Additionally we were hoping to not auto persist the workflow and wait to persist until after the Form is submitted. Everything works as expected when run from the Action Menu - but we've discovered that the behavior when launched from Connection Request is VERY different (and not right?).

These are 2 specific behaviors that we believe are NOT right...

1. Regardless of whether the workflow is persisted or not - it the workflow stops processing at a "Workflow Entry Show HTML" instead of a "Form" action - when the workflow is triggered from a Connection Request - the modal will appear saying the workflow was started - but the 2nd tab is never opened to show the UI for the workflow - so the user never sees what happened or the content of that message. BUT - it does show the UI when run from the Action Menu.

2. When the workflow is setup to NOT auto persist - if the workflow stops processing at a user entry form - then when run from Connection Request the modal will say the workflow was started and is ready for input ... but when the 2nd tab opens - the user gets an error saying the Entity was not specified

Actual Behavior

As described above ... the workflow's behavior is inconsistent when launched from Person Profile Action Menu vs a Connection Request.

Expected Behavior

The workflow's behavior should be the same (or at least consistent) when launched from Person Profile Action Menu vs a Connection Request.

Steps to Reproduce

Here are 2 workflows - setup the same - except 1 auto persists and 1 doesn't ConRqst WF (Auto Persisted)_202406060901.json ConRqst WF (Not Auto Persisted)_202406060902.json (NOTE: There are 2 Lava Run actions in each with hard coded EntityTypeIds for Person (15) & Connection Request (240) ... with the values for the demo site.) (2nd NOTE: For purposes of this test each workflow is setup to stop at a Show HTML action instead of the Form if the Person has a first name of Wendy ... for the demo site - Wendy Gilbert is a great test candidate)

1 - import the workflows (update the EntityTypeIds in the lava run action if needed) 2 - add these workflows to the Action Menu for Person Profile 3 - add these as manual triggered workflows for an Connection Type

To confirm behavior #1

1. Find a Person Profile whose first name is Wendy
2. Run either workflow from the Person Profile Action Menu for Wendy
3. Run the same workflow from a Connection Request for Wendy
4. Note the difference in behavior

To confirm behavior #2

1. Find a Person Profile whose first name is NOT Wendy (Brian Gilbert on the demo site is a good one)
2. First run the Auto Persisted version of the workflow from the Connection Request
3. You should see the user form in the 2nd tab that opens
4. How run the NOT Auto Persisted version of the workflow from the Connection Request
5. You should see an error message about the Entity not specified in the 2nd tab
6. Now run the same 2 workflows from the Action Menu - and note the behavior

(LAST NOTE: all of this is currently setup on the demo site if you want to quickly confirm the behaviors today)

Issue Confirmation

• [X] Perform a search on the Github Issues to see if your bug or enhancement is already reported.
• [X] Try to reproduce the problem on a fresh install or on the demo site.

Rock Version

16.2

Client Culture Setting

en-US

[stanalyst]

Also - a couple of us had a fairly big back-and-forth discussion on this topic in the workflow channel on RocketChat ... might be some more details there that are helpful. Thanks!

[JDShuman]

I was able to reproduce this on the demo site. I was looking for an existing workflow I could test on our setup, which is currently running v16.4, but it seems we are currently auto persisting workflows triggered from connection requests. We generally do not auto persist workflows that direct the user to a form, so I'm guessing we ran into this issue and set to auto persist as a workaround.

[nairdo]

@stanalyst The approach for launching a workflow from the Person Profile's Actions menu is much different than the mechanism for launching workflows from the Connection Request. I don't believe this is something that broke in v16.2.

If you'd like to submit a feature request for allowing a different approach to launching workflows from Connection Requests we'd like you to submit your idea over at the Ideas and Core Changes page.

[stanalyst]

Here's the idea -> https://community.rockrms.com/ideas/2005/updates-to-workflow-behavior-when-manually-triggered-from-connection-requests

[stanalyst]

Couple more thoughts on this:

@nairdo I agree that this isn't something that broke with v16.2. I actually think the design for manually triggering workflows from connection request has a deficiency in that not all features/methodology for workflows are supported.

Maybe until a change is made to all of this, it would be good to include a warning message in the documentation for workflows and connection requests? Maybe something like:

"Be careful turning off auto-persist if the workflow will be manually triggered from a connection request - as it may not perform as expected"

[nairdo]

@stanalyst Thank you for submitting the idea and for your additional feedback.

[JimMichael]

I'm gonna be the fly in the ointment (that I'm soooo good at being :-D ) and ask for the rationalization of how a workflow literally not working correctly when launched from Connections unless it is auto-persisted is considered an enhancement?

[nairdo]

@JimMichael It's not the enhancement. The approach taken when launching workflows from a connection request vs when launching them from the person profile action menu is different internal to Rock.

[JimMichael]

Well... of course it's different, no one is contesting that. The issue is why Spark thinks workflows launched from Connections are ok to behave in an inconsistent and undocumented way and instead suggest an Enhancement/Idea vs. considering it a bug.

And by "undocumented way" I'm meaning: you cannot launch a non-auto-persisted workflow from a Connection Request and get the passed Entity. In effect, every workflow launched from a Connection Request MUST be auto-persisted if you want to deal with the passed Entity... which of course you want to, which is the whole reason you're launching it FROM a Connection Request in the first place.

Needing to auto-persist all (Connection Request) workflows in this way is contrary to documented workflow best practices. At the very least the docs should have a note to reflect this inconsistency.

[nairdo]

Hi @JimMichael

And by "undocumented way" I'm meaning: you cannot launch a non-auto-persisted workflow from a Connection Request and get the passed Entity.

There might be a misunderstanding of the issue. In our testing, the entity is correctly passed to the workflow. When launching the workflow from the block, the entity is the Connection Request. This entity is accessible using the "Attribute Set From Entity" action. We've confirmed this works correctly whether the workflow is persisted or not.

Even if the workflow is not persisted, you can still use that Connection Request. In my case, I wrote an interaction record with it and converted it to JSON:

This was logged to my Interaction table:

Entity JSON = {
"ConnectionOpportunity":{...}
"ConnectionStatus":{...}
"CreatedSourceDate":{...}
"PersonAlias":{...}
"ConnectionOpportunityId":3,
"PersonAliasId":49,
"Comments":"I would love to help teach kids about Jesus.",
"ConnectionStatusId":1,
"ConnectionState":0,
"FollowupDate":NULL,
...
}

Please let us know how this differs from your understanding and what you're experiencing.

[JimMichael]

Thanks for your patience, @nairdo! It could be that I didn't state all the facts accurately (@stanalyst can chime in if he wants) but based on item 2 in the Description of this issue, it happens when you don't have a auto-persisted workflow AND a User form (at least that's how I read it... sorry I didn't spell that out, I assumed the original context of this issue and its details were still in scope ;-)

When the workflow is setup to NOT auto persist - if the workflow stops processing at a user entry form - then when run from Connection Request the modal will say the workflow was started and is ready for input ... but when the 2nd tab opens - the user gets an error saying the Entity was not specified

[stanalyst]

Scenario:

• Workflow is not set to auto persist.
• Action 1 is Set Attribute From Entity (with entity required set to yes) - to save the Connection Request to a WF attribute
• Action 2 grabs the Requestor from the Connection Request to save the Person to a WF Attribute
• Action 3 is a user entry form that displays the person info and prompts for message to email to person

If this workflow is manually triggered from a Connection Request - the user will see a modal message that the workflow has been launched and is ready for input. When they close that modal and are switched to the new tab with the workflow they will see an error that required entity was NOT provided.

I could be totally off - but my hypothesis is the workflow is running 2 times. Once when first triggered - and then again when they get to the page. The entity is available for the first instance - but NOT for the 2nd one.

[nairdo]

I wanted to give a little more explanation about why there is a difference between these two places to launch a workflow. When launching a workflow from the Action menu, we expect that you're going to be moved off the person profile and over to the workflow.

With Connection Requests, we expect you would remain on the connection request. In the rare case that your 'manual' Connection Request workflow has an active form action, some versions ago, we did add the ability to be taken over to the workflow. However to determine if there was an active form, involved starting the workflow to run it. That's where this sticky 'situation' occurs. If your workflow did not persist, then when you are sent over to the workflow it's actually running it again and the Entity is not available during that redirect.

We're going to look at this feature request again to see about passing that connection request entity (Guid) over to the workflow during the redirect so that non-persisted workflows could also work. However that does mean it would execute the workflow a second time if we do this.