#1MinuteTip Received an email today from Mason Frank containing link to download Mason’s Frank Careers & Hiring Guide for Salesforce. I haven’t gone through it entirely but found some interesting information like:
- Do Salesforce certifications help professionals stand out in a competitive job market?
- What percentage of candidates hold a salesforce certification?
- Top 10 certifications that will boost your pay
- Does salesforce trailhead increase your chances of gaining future employment?
- What are the top 5 attributes you need to be a contractor?
- What non-salesforce products are customers integrating salesforce with?
- What challenges do end users face when implementing Salesforce?
- Salesforce go-live delays
- How long were these delays?
- What factors caused the delay?
And one thing that all of us will be very interested in knowing 🙂
- How much do Salesforce professionals make in different roles like Admin, Developer, Consultant and Architect along with salary tables for US, Canada, UK, European countries & Australia
To download the guide please navigate to URL https://www.masonfrank.com/insights/salesforce-careers-and-hiring-guide
At times you may want to retrieve all the metadata from your Salesforce Org. This may be required to take a backup before a major deployment or for creating the “master” branch for your Source Control system like Git.
A Flow can be invoked from multiple places. You can invoke it from a button, embed it on your pages, invoke it when DML operations are performed, schedule to run it or even invoke it through REST API call.
In this step-by-step guide, you will learn how to call a Flow from an API, how to pass parameters to the Flow and how Flow will return the values back to the API
If you have worked with package.xml in Salesforce to retrieve or deploy components, you have seen the “<version></version>” tag. Do you know what exactly it does?
Version determines which version of Metadata API Salesforce will use to retrieve or deployment your components. And that will mean that only those properties will be retrieved or deployed that was available in that version.
Here is a package.xml file that I used to retrieve the same component (one custom object and one custom profile) with different versions. The Org that I used is currently on Winter ’22 Release of Salesforce (i.e. version 53.0)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Package xmlns="http://soap.sforce.com/2006/04/metadata"> <types> <members>Animal__c</members> <name>CustomObject</name> </types> <types> <members>AA System Administrator</members> <name>Profile</name> </types> <version>XX.0</version> </Package>
When we want to retrieve or deploy metadata to a Salesforce Org, we use package.xml either with ANT command or using SFDX. And when retrieving metadata from a Salesforce org, it is quite common to use wildcard character asterisk (*) to retrieve everything of that metadata type.
For example, the following is used in package.xml to retrieve metadata about all custom objects.
<?xml version=1.0 encoding=UTF-8 standalone=yes?> <Package xmlns=http://soap.sforce.com/2006/04/metadata> <types> <members>*</members> <name>CustomObject</name> </types> <version>53.0</version> </Package>
Traditionally, to control the visibility of records in Salesforce, we used to start with the most restrictive setting (i.e. setting OWD to Private for an object) and then opening up the access using various features like role hierarchy, sharing rules, teams etc.
Consider the following diagram. Before Restriction rules, we started with the most restrictive setting and then opened up access using various features.