Friday, April 29, 2016

Playing with Salesforce Custom Settings (List based)

Querying Custom Settings

While working with Custom Settings in Apex, it is possible to use both Salesforce provided instance methods to access the Custom Settings or to use SOQL to query the data in the Custom Setting.

The Salesforce provided methods are well known and are documented here - Custom Settings Methods [developer.salesforce.com]

Using SOQL to query the Custom Setting is possible since the Custom Setting is similar to a Custom Object. Salesforce does not recommend this since

  • this will not use the application cache
  • will count towards your SOQL query limit
Try this
  • Create a custom setting with one field
  • In the Developer Console anonymous apex window, query your Custom Setting in a loop through SQL to see if you can hit the governor limit [NOTE: do not use SOQL in loops in your production code - I'm just trying this to make a point]


  • Now try retrieving the Custom Setting data using the instance methods - no SOQL is used.
List<anilc__Testing__c> testData2;
for (Integer i=0;i<101;i++) {
    testData2 = anilc__Testing__c.getAll().values();
}



Custom setting field type mapping

While researching this post, I was trying out a lot of the allowed fields in a Custom Setting and querying them in Apex. One of the things I was looking at was the field types - what do they map to in Apex? I didn't see this documented anywhere, so I'm listing them here, after trying them out



Custom Setting Field Type Apex field type
Currency Decimal. You can use Double as well
Date Date
DateTime DateTime
Email String
Number Decimal. You can use Double as well
Percent Decimal. You can use Double as well
Phone String
Text String
TextArea String
URL String
Checkbox Boolean





References

  1. Custom Settings Methods [developer.salesforce.com]





Friday, April 15, 2016

Salesforce Integration notes

Create and use an Integration user with Admin profile

This is so that you have an integration user independent of your actual users. If you were to use an actual user, if and when they leave or change roles in your company, you'll have to configure another user. Don't do this and instead save yourself the trouble and create a user named Integration User instead. See reference 1 for more information about this.

You can also create one more user named Data Migration with the same configuration and use this for all data loads into Salesforce. This allows you to figure out if the record was created (or updated) by someone doing a data migration or was touched through external integration

Finally create one more similar user named Code Migration. This allows your deployment team to login to production and deploy code without having to reuse or know the Integration or Data Migration credentials.

Bypass Triggers for this Integration or Data Migration user

Turning off triggers in production is a pain and requires a changeset deployment to turn off. Instead while developing the trigger itself, add code to bypass it for the Integration and Data Migration users. This is something you'll need to be careful of, since in some situations you might need the triggers to fire. So think about this carefully

Bypass validation rules and workflows for this Integration or Data Migration user

When doing a data load or an API integration, you may not want any validations to occur or workflows to run. Add these users as a check in the validation rule and workflow so that the validation rule and workflow gets bypassed if the user name is Integration or Data Migration

Make Contacts owned by the Integration user

Contacts are normally owned by the user who created them. This causes an issue when the person leaves the organization which makes the contact uneditable (if org wide default is private or public read only). (This problem - editing records of inactive users - is solved in Winter 16 - see reference 3 below). Also record owners are able to delete contacts they own. To prevent this, write a workflow rule which changes the contact owner to the Integration user immediately on contact creation. Then share the contact (through criteria based sharing settings) with only the roles which need access

References


Thursday, April 14, 2016

Setting up single sign on (SSO) with Okta and Salesforce Community

Problem

Consider this: you have a salesforce instance (sales or service cloud) where single sign on (SSO) was already setup. Later when you create a community, you want to reuse the same SSO configuration done in Salesforce without having to create a multiple SAML configurations in Salesforce.

Unfortunately, salesforce documentation isn't very clear on how to do this when you already have SSO setup for the main instance. Hopefully these steps will help.

I had done this integration with Okta and Salesforce, so the steps below reference Okta as the Identity Provider (IdP). But the overall process should be the same

Prerequisites


  1. Your main instance (sales / service cloud) is already configured with SSO
  2. You have a few users setup with Community profiles/permissions in Salesforce
  3. install the SAML Tracer plugin in Firefox. You'll need this to help debug if there are any issues later

Step 1 : Prepare information for your IdP

In Okta, you'll need to create a new application integration with Salesforce for the community. You cannot use the existing Okta configured application for this. There is no way around this - while there will be a single SSO configuration in Salesforce, Okta will have two - one for the main Salesforce ServiceCloud and the other for the Community Cloud.

You'll need to provide information from your existing SSO setup in Salesforce. 

In Salesforce, Go to Setup-> Security Controls->Single Sign-On Settings

Okta needs the following values from your Salesforce instance
  • For the Okta Single Sign On URL & Recipient URL & Destination URL settings : provide your Community URL appended with the saml parameter from current instance. More on how to create this is below
  • For the Audience Restriction or Entity ID : Use the entity parameter from your Salesforce Single Sign On settings. Normally this is https://saml.salesforce.com

Other settings for Okta
  • Name ID Format :     Unspecified
  • Response :     Signed
  • Assertion Signature :    Unsigned
  • Assertion Encryption :     Unencrypted
  • SAML Issuer ID: Use the issuer parameter from your Salesforce Single Sign On settings

1a: generate the community SSO URL



The first part of the SSO URL will be either of the following
  • In production it will be the community domain you have setup with /login/ appended at the end – say, https://something.yourcompany.com/login/
  • In sandboxes, it will be the Force.com community site URL with /login/ appended at the end – https://yourcommunity.instance.force.com/login/. You can find the Force.com community site URL by going to Setup->Develop->Sites.
NOTE: The Site URL will show as http in the Salesforce Sites page (screenshot above), but you'll have to provide the https link.

The second part of the SSO URL will be the saml parameter from your existing SSO configuration in Salesforce
  • Go to Setup-> Security Controls->Single Sign-On Settings
  • Copy the saml= part of the Salesforce Login URL. This is what needs to be appended to the Community Login URL




Finally you'll get a URL which looks like this https://yourcommunity.instance.force.com/login/saml=somestring

Provide this to Okta as the Single Sign On URL

Step 2: Create the new application in Okta and add users to the new application in Okta

This step is done in Okta and will not be covered here. It's anyway specific to the IdP you choose.

Step 3: Test

Test the new SSO by going to the Okta Dashboard and logging in as one of the users assigned the application and clicking on the new application tile. Okta should drop you into the Community without having to relogin

Step N : Debug

This one is marked Step N since you'll be doing this multiple times :)


  1. In case there are issues, open up firefox and open the SAML Tracer extension
  2. Run through the login scenario and capture the SAML request. SAML Tracer helpfully marks this with a big SAML indicator on the right of the capture window
  3. copy the SAML post sent from the browser to SFDC and run it through the SAML Validator provided by SFDC. To use the SAML validator, go to Setup-> Security Controls->Single Sign-On Settings and Click on SAML Assertion Validator button.
  4. Paste in the SAML text and click validate
  5. The SAML Validator will provide a list of failures in red. 
    • First look if the identity is being passed correctly in the SAML assertion to Salesforce from the IdP
    • Next check if Salesforce could read the certificate passed from the IdP - this should not be an issue since the existing SSO configuration in Salesforce is being reused, so the certificates should already be installed in Salesforce




References


Saturday, April 2, 2016

How to setup your own domain for Community in Salesforce

Step 1: Register your domain name

Register your domain name in DNS and alias (CNAME) it to your Organization's site. This is done outside of Salesforce.

For example: if your domain is www.samplecommunity.com, you'll have to register it with a domain name provider and add a CNAME to www.samplecommunity.com.<insert your Salesforce siteID here>.live.siteforce.com

You'll find the Salesforce siteID by going to Setup->Domain Management->Domains

Note: Custom domains can only be used with production environments not sandbox


Screenshot of Domain setup


Step 2: setup the domain in Salesforce

Note: First check that the domain name you've created has propagated over the internet by doing a nslookup of the domain name from your local machine
Then in Salesforce, go to Setup->Domain Management->Domains
Enter the new Domain name you've created in the Domain Name text field. You don't need a certificate at this time.
Click Save.

Step 3: Obtain a SSL certificate for your domain

3a: Generate a Certificate Signing Request (CSR) and send it to your Certificate Authority (CA)

  • Go to Setup-> Security Controls-> Certificate and Key Management.
  • Click on Create CA-Signed Certificate and enter the following information. Click on Save
Common Name=<your domain name>
Department=<your department name>
Company=<your company's legal name>
City=<Your company's city>
State=<Your company's city>
Country Code=<two-letter ISO code for the country where your organization is located>
Key size=<either 2048 or 4096 bit - depending on what your CA supports>
Email Address=<preferably provide the email address of your salesforce administrator>

In the next screen, click on Download Certificate Signing Request. Provide this CSR file to the CA

3b: import the certificate into Salesforce and apply it to your domain

  • Once the certificate has been obtained from the CA, go back to Go to Setup-> Security Controls-> Certificate and Key Management and click the record you created the CSR for in Step 3a
  • Click on Update Signed Certificate to apply the new certificate
  • On the same screen, add the certificate to the domain by clicking on Add Domain

Step 4: Configure the domain to point to the community  

Note: your Community must be Published.
Go to the domain setup in Step 2. Click on Add Custom URL and enter the Community URL and save.

Step 5: Test

In a browser window, go to your domain name. The landing page of your community should show up!

References


  1. Configure a Custom Domain for Your Community[developer.salesforce.com]
  2. About Salesforce Certificates and Keys [help.salesforce.com]
  3. Certificate signing request [wikipedia.org]