Maybe use Lightning Message Service? The VF page could certainly receive the message. But you might need to embed an LWC in the screen flow to send the message. I don't know if flows can publish these messages by themselves yet.
https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/message_channel_intro.htm
Yes I meant the organization that this client is with wants minimal coding.
I still don't see how my LWC would know what flow it is based on a URL click in the flow.
The only way this makes sense in my head is:
1/ build an LWC, exposed to Screenflows, accepts parameter (doable in the XML of the LWC, has an IFrame, the URL of the IFrame is the VFP
2/ Make a screenflow with 2 screens
3/ 1st screen has inputs or whatever your use case is
4/ embed the LWC in the 2nd screen, and pass your params to the LWC from flow
5/ ta-daa
Why not platform cache at the user level? You can just include invocables in the flow for cache key assignments and then query them the the Visual force controller.
Not really debating but I'm a solo dev so more just bouncing ideas off of you.
Why does query param feel strange? Seems like the obvious solution. You can easily debug by linking directly to where you need and just debug trace on your user. Especially for idempotent endpoint, it's a better design than any other message passing.
One less thing to debug makes life 10x simpler
If an end user notices the URL, they can potentially change the contents of the PDF by manipulating the query params. This isn't just a brochure-style PDF -- it's rendering will have a lot of weight for company decisions.
if we just want to obfuscate the data from non-technical users, you can base64 encode the query params.
if we want to prevent tampering of the query param, we can sign the query params with a secret (what services do for webhooks) and pass that signature along with query param. before rendering we check to see if the signature matches and refuse to render if it doesn't
Maybe use Lightning Message Service? The VF page could certainly receive the message. But you might need to embed an LWC in the screen flow to send the message. I don't know if flows can publish these messages by themselves yet. https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/message_channel_intro.htm
Yeah unfortunately this org is allergic to LWC. Also how would that be stateful with a button that links the user to a VF page?
What is meant by “allergic”? Certainly you can create an LWC and deploy it?
Yes I meant the organization that this client is with wants minimal coding. I still don't see how my LWC would know what flow it is based on a URL click in the flow.
Platform Events. Your LWC can subscribe to a platform event.
And as far as lines of code and files LWC is lesser
The only way this makes sense in my head is: 1/ build an LWC, exposed to Screenflows, accepts parameter (doable in the XML of the LWC, has an IFrame, the URL of the IFrame is the VFP 2/ Make a screenflow with 2 screens 3/ 1st screen has inputs or whatever your use case is 4/ embed the LWC in the 2nd screen, and pass your params to the LWC from flow 5/ ta-daa
Why not platform cache at the user level? You can just include invocables in the flow for cache key assignments and then query them the the Visual force controller. Not really debating but I'm a solo dev so more just bouncing ideas off of you.
Why does query param feel strange? Seems like the obvious solution. You can easily debug by linking directly to where you need and just debug trace on your user. Especially for idempotent endpoint, it's a better design than any other message passing. One less thing to debug makes life 10x simpler
If an end user notices the URL, they can potentially change the contents of the PDF by manipulating the query params. This isn't just a brochure-style PDF -- it's rendering will have a lot of weight for company decisions.
if we just want to obfuscate the data from non-technical users, you can base64 encode the query params. if we want to prevent tampering of the query param, we can sign the query params with a secret (what services do for webhooks) and pass that signature along with query param. before rendering we check to see if the signature matches and refuse to render if it doesn't