Experience Workflow not triggering

Help
1

I don’t understand this paragraph, but I think I am runing into this issue:

A static reply is a page or a redirect that will be used as the response for this route. If either an Experience Page or redirect is selected, the workflows that are attached to the route will still run, but this response will take precedence over any workflow that would have sent a response itself.

I setup an endpoint GET / and it points to an Experience Page GET /devices which has a workflow that looks up the device assigned to the experience user’s group and then sends the user to /devices/{deviceId}/dashboard with the proper device Id and name.

When I login, I am sent to the /devices page, but I see the default custom content html of the /devices page instead of having the workflow trigger and send me to the correct /devices/{deviceId}/dashboard page. The odd part is that if I append my url in my web browser with /devices and hit enter, the correct /devices/{deviceId}/dashboard page loads.

I also tried skipping the /devices page and tied the experience workflow to the /devices/{deviceId}/dashboard page but the workflow still does not trigger when redirected from the GET / page.

Please let me know what I can provide to help explain this better.

John

2

I was thinking my issue was that I had two endpoints that started with the same /devices:

/devices
/devices/{deviceId}/dashboard

So I renamed the /devices endpoint to /helper. GET /helper has a workflow that looks up the device assigned to the experience user and then calls the /devices/{deviceId}/dashboard endpoint to display a dashboard.

In my application there is a one to one relationship between email address (experience user) and a single device. I don’t foresee a user having multiple devices. So, I don’t need a page where user would pick which device data to display on a dashboard.

What I am seeing is that when a user logs in, they are directed to the /devices/{deviceId}/dashboard via the GET /helper endpoint, but the workflow associated with GET /helper is not triggered. As a result,
the dashboard rendered by /devices/{deviceId}/dashboard is a default device - not the device associated with the user. The Experience render log shows: Page [GET /helper] rendered successfully in layout.

If I manually append /helper in my MS EDGE address bar and press enter, the dashboard that is shown in my browser is for teh decive associated with the logged in user and the render log shows: Page [GET /devices/{deviceId}/dashboard] rendered successfully in layout [layout]

Hopefully, this helps explain better what I am seeing.

Thanks again, John

3

I had to take a peek in your account as this all seems a bit tangled. Here’s what I am seeing …

  • On successful login, you are redirecting users to your home endpoint (GET /). This is good, standard practice.
  • The GET / endpoint is rendering a static reply page called “GET /helper” out of a static reply, which renders a dashboard that pulls properties off of the pageData object. However, no workflows are running that would construct that object. (The endpoint GET /helper is not getting hit in this scenario.)
  • When you manually visit GET /helper in your browser by typing it in, that does indeed run the “helper” workflow, which looks up the device, constructs the pageData object, and renders the “GET /devices/{deviceId}/dashboard” page.

I’m guessing a lot of the confusion here is related to what is handling an endpoint request vs. what is rendering content based on all the resources being named similarly. So let’s simplify this to the following …

  1. The endpoint GET / should do the following …
    • For signed-out (unauthorized) users, use a static reply to redirect to /login.
    • For signed-in users, run a workflow that, given a user, looks up their associated device ID however that association is done in your application and, in the Endpoint Reply Node, redirect to /devices/{{deviceId}}/dashboard - where {{deviceId}} is a string template pointing to the ID you looked up for the user.
  2. Then, have an endpoint for /GET /devices/{deviceId}/dashboard that does the following …
    • For signed-out users, use a static reply to redirect to /login.
    • For signed-in users, use a Device: Verify Node to ensure that the device ID in the URL is a device the user should have access to.
      • If they do, then construct your payload* (see note below) as you are doing now and use an Endpoint Reply Node to render the page that is displaying your dashboard with context variables set.
      • If they do not (the false path), render a 404 page and return a 404 status code using the Endpoint Reply Node.

*As for the payload, you are returning a device object on the pageData property and are using two properties: the device ID and the device name …

  • The device ID is already available in the URL (accessible as {{request.params.deviceId}}.
  • The device name could be made available within the dashboard’s context configuration by selecting the “Include full device info in context” option - though doing this will also, through the network requests, expose other information on the device such as tag values. If you are not storing anything sensitive in those tags, you could enable this option and then have access to the device name, within the dashboard under the variable {{ctx.deviceId.name}} - in which case you do not need to construct the payload within the workflow. But you’ll still need the flow for the Device: Verify Node, without which you risk exposing Customer A’s data to Customer B.
4

Thank you! Everything is working now.

I don’t know why, but I “assumed” that you weren’t supposed to put workflows in the GET / endpoint. (No idea where I came up with that rule BTW :man_shrugging:)