#Formulas토론 중인 항목 40개

 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. 😊 

@Craig Munster

Ah, that's the missing piece — and you're right, I was wrong to steer you off your formula field. On an Opportunity Product button the native OpportunityId genuinely isn't exposed in the merge-field picker (annoying known quirk). Your Opportunity_Id__c CASESAFEID field is exactly the right workaround, so keep it — custom fields DO show up under Insert Field. Just reference that one instead of OpportunityId: 

/flow/Opportunity_Product_Screen_Flow_Clone_Opportunity_Product?recordId={!

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

That sends them back to the Products related list on the parent Opp. Sorry for the runaround getting there! 

If this helps, please mark it as the Best Answer so it helps the next person — thanks 🙂

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 🙂