Hello all,

I've built a screen flow that uses the component visibility feature extensively.  It was all working fine in debug until I activated the flow; now, many of my screen components won't appear under any conditions.  Visibility settings seem to work for criteria based on flow picklists and record fields, but not when they're based on flow checkboxes and formulae.

As an example, on the first screen of the flow, the second "Address to be Validated" component is causing trouble:



The address component should be visible if the checkbox {!Match_Address} is set to false OR the picklist at the top of the page {!AddType} is set to something other than the default choice.


When the flow runs, changing the picklist selection does change the address component's visibility, but clicking and unclicking the checkbox does not.  Before I activated the flow, it had been working properly in debug.  There are about a dozen components in the flow showing similar behavior.

The flow was built in a Summer '20 sandbox.  I don't see anything in the release notes that would account for what I'm seeing.  Does this sound familiar to anybody?

Hello, Would someone be able to assist in writing a test class for the following apex class:
global class purgeFiles implements Schedulable{
    
    global void execute(SchedulableContext SC) {
        
    List<ContentDocumentLink > docs;
        docs = [SELECT Id, Linkedentity.name, Linkedentity.id,ContentDocument.CreatedDate  
                FROM contentDocumentLink 
                WHERE Linkedentityid 
                IN (SELECT Id FROM lead where createddate < Last_N_Days:7 and isconverted = false) ];  
                //may want to change to include ALL leads
                //AND ContentDocument.CreatedDate < Last_N_Days:7];
                if(!docs.isEmpty())
            delete docs;
    }
}

Thank you very much

In Objective C, I follow the steps as outlined here and it works fine: https://developer.salesforce.com/docs/atlas.en-us.noversion.mobile_sdk.meta/mobile_sdk/ios_rest_apis_using_methods.htm?search_text=forceios

But when following the same steps translating the code into Swift, I run into an issue with the SFRestRequest initializer, whose signature is below:
 

Public convenience init(method: SFRestMethod, path: String, queryParams: [String : String]?)

As you can see, queryParams takes a Swift Dictionary with a key and value of the String type.  But when you follow the example, it seems you end up with a Dictionary with a key of the String type and value of the Dictionary type; and thus we have a type mismatch.

This doesn't seem to be a problem in Objective C, because upon inspection of the method signature in SFRestRequest.m, queryParams appears to be able to take a generic NSDictionary: 
 

+ (instancetype)requestWithMethod:(SFRestMethod)method path:(NSString *)path queryParams:(NSDictionary *)queryParams

For reference here is the Swift code I'm trying out:
 

//build the queryParams dictionary from a JSON String
let body: String = "{ \"body\" :{\"messageSegments\" :[{ \"type\" : \"Text\",\"text\" : \"My Comment\"}]}}"
        let queryParams = SFJsonUtils.objectFromJSONString(body) as! [String:AnyObject] 
//construct and send the request
        let request = SFRestRequest(method: SFRestMethod.POST, path: "/services/data/v36.0/connect/communities/my_community_ID/chatter/feed-elements/my_element_ID/capabilities/comments/items", queryParams: queryParams as? [String:String])
        SFRestAPI.sharedInstance().send(request, delegate: self)

But unwrapping queryParams fails and resolves to nil.  Trying to forcefully cast queryParams to [String:String] does not work either, and just causes a crash.

How might I get around this?