Variable falsely flagged as UnusedVariable when used in Text Templates

[filiprafalowicz]

When sending emails directly from the Flows, we need to very often use Text Templates resource which may use some formulas to dynamically generate email content based on the criteria. However for this scenario, lightning flow scanner will report UnusedVariable rule violation as Text Templates are not included in the logic that searches for variable usage.

Below is a sample flow that will trigger rule violation:

<?xml version="1.0" encoding="UTF-8"?>
<Flow xmlns="http://soap.sforce.com/2006/04/metadata">
    <actionCalls>
        <name>Send_Email</name>
        <label>Send Email</label>
        <locationX>176</locationX>
        <locationY>323</locationY>
        <actionName>emailSimple</actionName>
        <actionType>emailSimple</actionType>
        <flowTransactionModel>CurrentTransaction</flowTransactionModel>
        <inputParameters>
            <name>emailSubject</name>
            <value>
                <stringValue>My Subject</stringValue>
            </value>
        </inputParameters>
        <inputParameters>
            <name>emailBody</name>
            <value>
                <elementReference>myTextTemplate</elementReference>
            </value>
        </inputParameters>
        <inputParameters>
            <name>recipientId</name>
            <value>
                <elementReference>$User.Id</elementReference>
            </value>
        </inputParameters>
        <nameSegment>emailSimple</nameSegment>
        <versionSegment>1</versionSegment>
    </actionCalls>
    <apiVersion>60.0</apiVersion>
    <environments>Default</environments>
    <formulas>
        <name>myFormula</name>
        <dataType>DateTime</dataType>
        <expression>NOW()</expression>
    </formulas>
    <interviewLabel>SendEmailFlow {!$Flow.CurrentDateTime}</interviewLabel>
    <label>SendEmailFlow</label>
    <processMetadataValues>
        <name>BuilderType</name>
        <value>
            <stringValue>LightningFlowBuilder</stringValue>
        </value>
    </processMetadataValues>
    <processMetadataValues>
        <name>CanvasMode</name>
        <value>
            <stringValue>AUTO_LAYOUT_CANVAS</stringValue>
        </value>
    </processMetadataValues>
    <processMetadataValues>
        <name>OriginBuilderType</name>
        <value>
            <stringValue>LightningFlowBuilder</stringValue>
        </value>
    </processMetadataValues>
    <processType>AutoLaunchedFlow</processType>
    <start>
        <locationX>50</locationX>
        <locationY>0</locationY>
        <connector>
            <targetReference>Send_Email</targetReference>
        </connector>
        <object>Account</object>
        <recordTriggerType>Create</recordTriggerType>
        <triggerType>RecordAfterSave</triggerType>
    </start>
    <status>Draft</status>
    <textTemplates>
        <name>myTextTemplate</name>
        <isViewedAsPlainText>false</isViewedAsPlainText>
        <text>&lt;p&gt;{!myFormula}&lt;/p&gt;</text>
    </textTemplates>
</Flow>

I think the issue is caused by textTemplates element being defined as flowMetadata instead of flowVariables in the Flow.ts file.

[RubenHalman]

@filiprafalowicz thank you for getting involved. We will try to create a test for this and reproduce it. I'm just curious how you are using lightning flow scanner and which version?

[filiprafalowicz]

@RubenHalman I have added Lightning Flow Scanner as part of my PR validation pipeline and the project I am working on currently is heavily leveraging flows. This is why I have been reporting all of these issues / enhancements recently.

I was using version 2.17.0 of the main plugin, but I see 2.19.0 was released recently so I will upgrade the plugin on my side.

[RubenHalman]

@filiprafalowicz Thanks, I just wanted to make sure you are using the sfdx plugin. I think you are right on your initial analysis. l have created this PR as an initial starting point for this issue, which includes a new test case based on the flow you provided.

[RubenHalman]

@filiprafalowicz this has been resolved with version: "3.6.0", which I will soon publish in both the vsc and sf cli solutions