#Formulas36 utenti parlano di questo argomento

Hi @Deepak Sachdeva

, 

Thank you for the suggestion. I tried that, exactly as you laid out, but it still did not work.  

I am happy to announce, however, that I spoke with Salesforce support on Friday and they did get it to work. Confusingly, it was one of the options I had tried before, which is in the list of my original post.  

This is the URL that worked:  

/flow/Opportunity_Product_Screen_Flow_Clone_Opportunity_Product?recordId={!

OpportunityLineItem.Id

}&retURL=/lightning/r/Opportunity/{!OpportunityLineItem.Opportunity_Id__c}/related/OpportunityLineItems/view 

Hi John, the ROUND(..., 2) approach is correct for limiting the calculated result to 2 decimal places. 

One thing to check is the data type of the Flow formula resource. Make sure the formula resource is set to Currency, rather than Number/Text, and that you aren't converting the Currency field to another type elsewhere in the Flow. 

You can also simplify the formula slightly: 

ROUND(
    IF(
        NOT(ISBLANK({!Get_Discount_Codes_with_Discount_Percentage.Discount_Amount__c})),
        {!Get_Discount_Codes_with_Discount_Percentage.Discount_Amount__c},
        IF(
            NOT(ISBLANK({!Get_Discount_Codes_with_Discount_Percentage.Discount_Percent__c})),
            {!Get_EventClass_Records.Course__r.Course_Fee__c} *
            ({!Get_Discount_Codes_with_Discount_Percentage.Discount_Percent__c} / 100),
            0
        )
    ),
    2
)

Also, if the value is displaying as something like 500.00500 despite the underlying Currency field being (16,2), the extra digits may be coming from how the Flow output is being displayed/formatted, rather than from the Currency field itself. 

 Hi Mark,

You can add an exception for Closed Lost by checking the previous Stage. Since you want users to be able to move directly to Closed Lost only when the Opportunity has already reached at least Still Qualifying Opportunity, you can wrap your existing logic with an exception like this:

AND(
    ISCHANGED(StageName),
    NOT(
        AND(
            ISPICKVAL(StageName, "Closed Lost"),
            CASE(
                PRIORVALUE(StageName),
                "SQLs to be allocated", 1,
                "Still Qualifying Opportunity", 2,
                "Requirements Captured", 3,
                "Proposal Generated", 4,
                "Negotiation", 5,
                "Deal Committed", 6,
                "Closed Won", 7,
                "Closed Lost", 7,
                0
            ) >= 2
        )
    ),
    CASE(
        StageName,
        "SQLs to be allocated", 1,
        "Still Qualifying Opportunity", 2,
        "Requirements Captured", 3,
        "Proposal Generated", 4,
        "Negotiation", 5,
        "Deal Committed", 6,
        "Closed Won", 7,
        "Closed Lost", 7,
        0
    )
    >
    CASE(
        PRIORVALUE(StageName),
        "SQLs to be allocated", 1,
        "Still Qualifying Opportunity", 2,
        "Requirements Captured", 3,
        "Proposal Generated", 4,
        "Negotiation", 5,
        "Deal Committed", 6,
        "Closed Won", 7,
        "Closed Lost", 7,
        0
    ) + 1
)

The important part is the exception:

AND(
    ISPICKVAL(StageName, "Closed Lost"),
    <prior stage value> >= 2
)

So Still Qualifying Opportunity or any later stage can move directly to Closed Lost, while an Opportunity still in SQLs to be allocated cannot. 

Hi Barb,

You can handle this with a Validation Rule using REGEX(). For example, if the field is Phone:

AND(
    NOT(ISBLANK(Phone)),
    NOT(REGEX(Phone, "^\\+[0-9]+$")),
    OR(
        LEFT(Phone, 2) <> "+1",
        LEN(Phone) <> 12
    )
)

However, because you want US numbers to be exactly +1 + 10 digits, while international numbers can have different country-code and phone-number lengths, I’d recommend separating the US and international checks:

AND(
    NOT(ISBLANK(Phone)),
    NOT(
        OR(
            REGEX(Phone, "^\\+1[0-9]{10}$"),
            REGEX(Phone, "^\\+[2-9][0-9]{6,14}$")
        )
    )
)

This requires:

• + at the beginning
• digits only after +
• US: exactly +1 followed by 10 digits
• International: + followed by 8–15 digits, with no dashes/spaces

You can adjust the international length if your organization's phone-number requirements are more specific. 

Hi Sean,

Yes, the Known Issue indicates that ISCLONE() in the Start/entry criteria of a record-triggered Flow cannot be used with Flow Debugging. The limitation is specifically with debugging the flow when ISCLONE() is part of the entry criteria. 

And I agree that moving the check into a Decision element isn't exactly equivalent—the flow has already started, so it doesn't test the same entry-condition behavior. 

For testing, one workaround is to temporarily move the ISCLONE() logic into a Decision element while validating the rest of the flow, then restore it to the Start criteria. For the actual platform limitation, I'd also keep an eye on the Known Issue for any status/update from Salesforce. 

Hi @Scott Holmes

Yes, you can check the formula syntax directly in Flow Builder. Formula resources are created within the Flow, so you won't find their syntax in Object Manager.

To view the syntax:

1. Open your Flow in Flow Builder.
2. Go to the Manager tab.
3. Under Resources, select your Formula resource (Due in 7 Days / Due in 2 Days).
4. Open the formula to view or edit its syntax.

For example:

Due in 7 Days:

{!$Record.ActivityDate} = TODAY() + 7

Due in 2 Days:

{!$Record.ActivityDate} = TODAY() + 2

You can also review Salesforce's formula documentation for additional functions and syntax. 

Hope this helps!  

 If you find this response helpful, please mark it as the Accepted Answer, as it may also help other Trailblazers facing a similar issue. 😊 

Hi Tarah, 

I have reviewed the Row-Level Formula and identified the issue with the formula structure. The IF() statements were being used inside the OR() condition, which was causing the “Missing )” error.

I have restructured the formula to validate the required conditions correctly: 

 IF( Churn_Event__c.Effective_Date__c > TODAY(), IF( OR( AND( ISPICKVAL(Churn_Event__c.Save_Successful__c, "yes"), Churn_Event__c.Total_Amount_of_ARR_Churned__c < Churn_Event__c.Churned_Revenue__c ), AND( ISBLANK(Churn_Event__c.Save_Successful__c), Churn_Event__c.Total_Amount_of_ARR_Churned__c = Churn_Event__c.Churned_Revenue__c ), AND( ISPICKVAL(Churn_Event__c.Save_Successful__c, "no"), Churn_Event__c.Total_Amount_of_ARR_Churned__c = Churn_Event__c.Churned_Revenue__c ) ), "Yes", "No" ), "No" )  

This formula returns

@Alex Valavanis

Because the status lives on the Fund record, reach it cross-object — a lookup lets you reference the parent's fields with the __r syntax, so Fund__r.Fund_Status__c works even though it's a formula field. Put this on the Opportunity validation rule (it fires / blocks the save when TRUE): AND( RecordTypeId = "01220000000AOdBAAW", OR(ISNEW(), ISCHANGED(Fund__c)), OR(Fund__r.Fund_Status__c = "Liquidated", Fund__r.Fund_Status__c = "Liquidating") ). The OR(ISNEW(), ISCHANGED(Fund__c)) limits it to when the Fund is actually being set or changed, so records that already point to a fund aren't locked if that fund later goes into liquidation. Two tips: match the exact text your Fund_Status formula outputs (the comparison is case-sensitive), and consider RecordType.DeveloperName = "Your_RT_API_Name" instead of the hardcoded Id so it survives sandbox refreshes and deploys. if this helps, please mark it as the Best Answer so it helps the next person — thanks 🙂