Solution user info from dashboard button trigger


I have a button trigger in an Input Control block on my dashboard that I’d like to use to export data for a Solution user and send to their email. Is there a way to pass the currently logged-in Solution user to the workflow triggered by the button?


The workflow payload actually already has information about what solution user pressed the button. There will be two fields on the payload - relayType, which will be solutionUser if a solution user pressed the button, and relayId, which will be the ID of that solution user. Hope that helps!


Ah I see that now, thanks. What is the best way to retrieve user info in a workflow based on this ID? I can query the solution users API endpoint using Postman, but I don’t see it listed in the Losant API node.


Unfortunately, it is not listed in the Losant API node because the Losant API node runs authenticated as an Application, and Solution Users live at a level above applications - applications don’t have permission to see or access them. This one of the reasons we moved away from Solutions/Solution Users and created the whole Experience/Experience Users feature set - since Experiences and Experience Users belong to an application, it is much easier to work with them in workflows.

One potential workaround in your case, in order to query the Solution User api endpoint, you could use the HTTP node and query the Losant API with an auth token that has permissions to hit the solution user endpoint.


That auth token would need to have viewer permissions at the organization level, correct? Which would mean it would have to be retrieved from the /auth/user endpoint based on an existing account. I think the preferred workaround for us would be to let the user input the email address they want the data sent to when exporting the data.

The long-term answer is probably switching over to Experiences now that Experience pages, and specifically dashboard pages, are available. Thanks for your help Michael, I think I understand the options we have moving forward.


Yup, you are correct, and your workaround would also work (and probably be more flexible as well)!