jq and multi-field output to CSV

jq is some of the most underrated tools out there I think. It’s a command line JSON parser that makes it super easy to work with JSON on the command line and in turn makes developing small SalesforceDX tools a breeze. Today I needed to generate a CSV file of all fields from different objects for the integration team that doesn’t have access to Salesforce. Doing the describe is easy using the Salesforce REST API but when using jq different are usually on different lines like below (-r is a nifty switch for getting raw, unquoted strings).

$ sfdx force:schema:sobject:describe -s Account -u myorg --json | jq -r ".result.fields[] | .label, .name"
Age
Age__pc
PO Box
PO_Box__pc
Postal Code Before City
Postal_Code_Before_City__pc
Street No Before Street
Street_No_Before_Street__pc
Archived State
Archived_State__pc

The output is almost what I wanted but really wanted not  to have to edit the file manually to build the output. Some quick googling and it appears that jq supports both CSV and tabular output from arrays. So fixing the issue was as simple as follows:

$ sfdx force:schema:sobject:describe -s Account -u myorg --json | jq -r ".result.fields[] | [.label, .name] | @csv"
"Age","Age__pc"
"PO Box","PO_Box__pc"
"Postal Code Before City","Postal_Code_Before_City__pc"
"Street No Before Street","Street_No_Before_Street__pc"
"Archived State","Archived_State__pc"

This is so cool… Love it!!

Trying to explain Person Accounts in Salesforce

Person Accounts in Salesforce keeps confusing developers not at home on the platform due to their special behaviour. The purpose of the repo (https://github.com/lekkimworld/salesforce-personaccount-field-reference) is to hold some examples on how to work with Person Accounts in an org using Apex and the Bulk API to try and illustrate a few points.

What ARE PersonAccounts

First of knowing WHAT a Person Account is is important. In Salesforce we normally talk about Accounts and Contacts with the Account being the company entity (i.e. Salesforce.com Inc.) and the Contact being the people that we track for that company (i.e. Marc Benioff, Parker Harris etc.). It means that we have to have an Account and a Contact to track a person in Salesforce. But what if that doesn’t make any sense like when tracking individuals for B2C commerce or similar? Meet the PersonAccount.

Please Note: There is no such object as PersonAccount in Salesforce. There are only Account and Contact but in the following I’ll use PersonAccount to reference this special case for Account.

PersonAccount is a special kind of Account that is both an Account AND a Contact giving you the possibility to treat an individual using an Account. The secret to understanding PersonAccount is knowing that using a special record type and specifying it when you create the Account, Salesforce will automatically create both an Account AND a Contact record and automatically link them and thus create the PersonAccount. Salesforce automatically makes the fields that are normally available (including custom fields) on the Contact available on Account. Only thing you need to do is follow a few simple rules that are listed below.

Please Note: When using PersonAccounts you should always access the Account and never the associated Contact.

Referencing Fields

Because there is both an Account and a Contact for a PersonAccount there are some special rules to follow when referencing fields. This goes for any access whether that be using Apex, REST API and the Bulk API. The rules are pretty easy and are as follows:

  1. Always reference the Account object
  2. When creating a PersonAccount create an Account specifying the record type ID of the PersonAccount record type configured in Salesforce. Doing this makes the Account a PersonAccount.
  3. Fields from Account are available on Account (as probably expected):
    1. Standard fields from Account Referenced using their API name as usual (i.e. Site, Website, NumberOfEmployees)
    2. Custom fields from Account Referenced using their API name as usual (i.e. Revenue__c, MyIntegrationId__c)
  4. Fields from Contact are available directly on Account:
    1. Standard fields from Contact The API name of the field is prefixed with “Person” (i.e. Contact.Department becomes Account.PersonDepartment, Contact.MobilePhone becomes Account.PersonMobilePhone) UNLESS we are talking FirstName and LastName as they keep their names (i.e. Contact.FirstName becomes Account.FirstName, Contact.LastName becomes Account.LastName)
    2. Custom fields from Contact The field API name suffix is changed from __c to __pc (i.e. Contact.Shoesize__c becomes Account.Shoesize__pc)

Delete Sample Data

One of my pet peeves in Salesforce has been solved. There is now a “Delete Your Sample Data” action under “View All” in Recommended Setup in “Service Setup” in Salesforce orgs. It’s no secret that I find it strange that we pollute new customer production orgs with sample data by default instead of asking the customer whether to add it. So I’m very happy that the process of removing it has become easier and we do no longer leave it to the customer to figure out the correct sequence for data deletion.

delete_sample_data

How to add missing SalesforceDX org alias

If you ever added a non-scratch org in SalesforceDX but forgot to add an alias using –alias / -a or simply want to change an alias there is a way easier way when readding all orgs. Simply edit the alias.json file as below.

  1. Locate your SalesforceDX settings directory (on Mac that is in ~/.sfdx and on Windows it seems to be %USERPROFILE%\.sfdx)
  2. Edit the alias.json file (please note that it uses Unix style endings so use an appropriate editor)
  3. Add missing alias mapping or correct incorrect mappings. The file simply maps an alias to the org username shown in “sfdx force:org:list”. Below is an example file.
{
 "orgs": {
   "example.qa": "mheisterberg@example.com.qa",
   "example.uat": "mheisterberg@example.com.uat"
 }
}

Issue with importing keystore into Salesforce

When attempting to import a certificate from a Java keystore (JKS) into Salesforce using “Security | Certificate and Key Management” under Setup the following error is encountered:

Data Not Available
The data you were trying to access could not be found. It may be due to another user deleting the data or a system error. If you know the data is not deleted but cannot access it, please look at our support page.

Resolving the issue is easy once you know how:

  1. Go To Setup | Identity Provider
  2. Press “Enable Identity Provider” button (Enabling this option will not affect any existing functionality in the Org. The full Identity Provider setup would need several other steps as well so enabling simply under — Setup | Identity Provider– will not make any difference so it can be enabled safely.)
  3. Once Identity Provider is enabled in the Org, it will create a self-signed certificate in your Org under — Setup | Certificate and Key Management
  4. Try to import the certificate from your JKS through “Import from keystore” option and it should be successful.
  5. (This is optional step) You may disable the Identity Provider again and then delete the automatically created Self-Signed certificate (via step 3) under ‘Certificate and Key Management’. This will turn your Org setup to its original state.

 

Life at Salesforce Through a Techie’s Eyes

I’ve been profiled in a post on Salesforce.com in a post titled Life at Salesforce Through a Techie’s Eyes. The post outlines how I see Salesforce as an employer and how I got to work for Salesforce. Sweet!

Only thing I saw that was stripped is the last sentence from the “Quick facts about me” section. It was “Even though I work under a blue cloud I continue to bleed yellow”. Oh well… 🙂

Bash one-liner for Apex test coverage percentage using SalesforceDX

Update 3 May 2018: There are issues with the percentages reported by SalesforceDX plus it doesn’t report coverage on classes with 0% coverage which will shrew the results. The approach outlined above can be used as an indication but cannot as of today be used as a measure for code coverage when it comes to production deployments. As an example I’ve had the above snippet report a coverage of 88% where as a production deploy reported 63% coverage. We – Salesforce – are aware of the issue and are working to resolve it. Stay tuned!

Note to self – quick note on how to run all tests in a connected org (as identified by the -u argument) and use jq and awk to grab the overall test coverage percentage.

$ sfdx force:apex:test:run -u mheisterberg@example.com.appdev -c -w 2 -r json | jq -r ".result.coverage.coverage[].coveredPercent" | awk '{s+=$1;c++} END {print s/c}'
> 88.1108

YMMV!