It apparently runs as the "Automated Process" user.
I see mention of it here https://jenwlee.com/2019/10/01/schedule-a-flow/
More importantly, I scheduled a quick flow to test this and I can see through debug logs that the scheduled flow was executed by the Automated Process User as opposed to the user who scheduled it.
In short: I managed to do this in Apex by using apex-mdapi AFTER I updated the code to support flowAccesses. - here's the github commit with changes needed to support it. This is the only way I can see to do this through Apex as you need to hit the Metadata API.
Very Long Version
I didn't see anything within SOQL or Tooling API that can be used. It seems ...
Yes you can, your component needs to implement lightning:availableForFlowScreens , the variable name in flow should match the attribute name in your lightning aura component.
<aura:component implements="lightning:availableForFlowScreens" access="global">
<aura:attribute name="greeting" type="String" access="global" />
Generic SObject and SObject are not yet supported at the interface between LWC and Flow (TLDR: You can't get there from here). We're working on it right now, though, and hope to get it into Summer '20. You can get an early taste for some of the experience by looking at how we implemented it for Apex Invocable Actions in Spring '20
We don't have any short-...
It is not possible at least according to Salesforce help page. In the Salesforce help Considerations for the Apex-Defined Data Type article has a Section on Input and Output values and it says:
An Apex-defined variable value can't be set or stored outside the flow.
The value can't be passed to a Subflow element.
go to screen( Contact Info) -> click Toggle -> scroll down the menu of toggle -> "Uncheck" Manually assign variables (advanced).
open decision -> click "add condition" enter update_toggle @ resource -> value. ;)
As tugce mentioned, an object-specific quick action will allow you to launch a screen flow by pressing an action button on a Lightning Record Page.
Make sure there is at least one active version of your screen flow, and add the action to the relevant page layout of course.
It's definitely possible to break out of the loop with a decision and directing the flow out of the loop, as suggested in the link you provided.
I think in your case you should go directly to Create Record from the 'Applicable SP Role = ..' negative decision, instead of going back into the loop to wait for it to finish all iterations and check the variable ...
Values that change in a given screen won't affect the value of any other component on the page. The only thing that listens for changes in the screen at runtime is the conditional visibility -- otherwise, the changes are only registered when the Next button is clicked and everything is sent to the flow engine on the server.
If you want to set a value in the ...
Your condition for visibility is checking whether RadioButton1 equals $GlobalConstant.True. But if you want the Stores Issues radio group to be displayed based on what's selected in the Call Category radio group, what you need to check is what the value of the radio button group is. In your example, RadioButton1 is a Choice resource, not a radio group.
Based on my experience and verified by other posts around the internet (https://success.salesforce.com/answers?id=9063A000000lObxQAE) I don't think what you want is directly possible.
The reason is, in a flow, you are not binding the Picklist directly to a record in the same way you do when creating Visualforce pages or components. The screen component ...
Thank you for your interest in accessing the Task object from UI API.
My name is Jonathan Au. I'm the PM for UI API. I'd like to let you know that this object is on our radar, but due to some complications related to the internal implementation of Task, enabling this object for UI API is not a straightforward process.
At this time, we do not have a ...
Two main approaches come to mind:
1) Set up conditional visibility
Including two instances of the second input component in the screen
Making one required, and the other optional
Setting up conditional visibility on them so that only one is displayed at a time (based on whether or not it should be required)
You could use decision and assignment elements ...
Lookup field must actually be a field of lookup type.
To query for a user object for example, on the lookup component you could select an Object API Name of value "Case" and Field API Name of value "CreatedById" and this appears to perform a SOSL lookup of all fields on the User Object since CreatedById is of field type: Lookup(User).
Thank you all for putting me in the right direction.
I made some more research and found out that as @KrisGonsalvez says, the flow runs as an Automated Process user. And as I could find out in the post I mention below, is that autoflows always run in System Context. So it's kind of a way of bypassing the permissions limitations.
How to By-pass User ...