Showing posts with label Salesforce. Show all posts
Showing posts with label Salesforce. Show all posts

02 December 2016

Community Cloud Certification Tips




I decided to take to community cloud certification before the end of this year because I think there are a lot of opportunities in the market right now that requires specialisation on implementing communities. Having been involved in the old customer/partner portal implementations as well as a community implementation 2 years ago when it was still in beta, I felt that this is the best time to take it since the functionality is growing every release.

Anyway, this post is about what I think you should be aware of and take time to review when you take the exam and so that you can pass it.
  1. Understand data access using sharing set, sharing group, OWD
  2. Opening data access using super user access (for partner and customer community plus licenses)
  3. What objects each community license types provides access
  4. Difference between Private and Unlisted groups for community collaboration
  5. Live agent setup with Communities
  6. Setting up multi-language with Communities
  7. Providing public access to Communities
  8. Benefits of using custom domains for Communities
  9. Community limits (# of keyword in a list, # of moderation rule etc)
  10. Other specific things such as:
    1. What are the available lightning components in Home page
    2. Managing recommendations
    3. Setting up Community Logo on login page
    4. What are the scenario the welcome email will get sent 
    5. Which template is Salesforce1 ready 
    6. What type of changes can be done on the community page header
Most of the questions are scenario-based that will ask which implementation options are efficient (yes, multiple answers). There are tricky questions that will really test your Salesforce knowledge not just for Community functionalities. 

For some reason, I thought that this certification is the easiest compared to Sales and Service Cloud. I didn't get any question related to community integration like question and answer and escalate-to-case, community rollout process and measuring community success thru reports and dashboard.
     

18 April 2015

Rollout your own limit dashboard




Spring 15 release brings some goodies as usual. One particular feature I liked is the REST API Limit Resource feature which will be in GA and will be available 24 hours after the scheduled release. I particularly like this feature, which I even sign up for a developer a preview a couple of months back, is because I'm annoyed with the system lack of dashboard page that allows me to track whether I'm almost hitting organisation limits. Simple requirement such knowing how many mail SingleEmail have been sent out requires you to contact Salesforce contact centre. Now it might be a product strategy from the San Francisco company as some of these limits (soft limits) can be increase by buying it in addition to the editions hard limits, or maybe just really not in the roadmap yet. We don't really know for sure but its good that developers and in some ways, administrators now has a way to check these limits without calling support.

Here are the limit information the the feature currently returns:
  • Daily API calls
  • Daily Batch Apex and future method executions
  • Daily Bulk API calls
  • Daily Streaming API events
  • Streaming API concurrent clients
  • Daily generic streaming events (if generic streaming is enabled for your organization)
  • Daily number of mass emails that are sent to external email addresses by using Apex or Force.com APIs
  • Daily number of single emails that are sent to external email addresses by using Apex or Force.com APIs
  • Concurrent REST API requests for results of asynchronous report runs
  • Concurrent synchronous report runs via REST API
  • Hourly asynchronous report runs via REST API
  • Hourly synchronous report runs via REST API
  • Hourly dashboard refreshes via REST API
  • Hourly REST API requests for dashboard results
  • Hourly dashboard status requests via REST API
  • Daily workflow emails
  • Hourly workflow time triggers
How to normally check the limit usage

Before we delve into how we can expose the limit information, lets take a look first on how we can normally access it. I will use workbench here for the purpose of simplification but feel free to use any tool of your liking.


Basically, we just need to go to the REST Explorer section of Workbench. Then you type in then limit resource url /services/data/<version>/limits/, then choose the GET option and then click Execute button.


Note that this is only available for REST API version 29 and to users with "View Setup and Configuration" permission. The DataStorageMB and FileStorageMB limits will only show for users with if "Managed Users" permission. 

Rolling out your custom limit dashboard

Administrators wouldn't want to always execute a REST call just to see the limit usage for the environment. What is needed is a dashboard the shows the current usage versus the hard limit. Below is a simple Visual force page executing a JavaScript to retrieve the same limit information.


<apex:page>
    <script type="text/javascript">
        var xmlhttp = new XMLHttpRequest();
        var url = "/services/data/v32.0/limits/";

        xmlhttp.onreadystatechange=function() {
            if (xmlhttp.readyState == 4 && 
                xmlhttp.status == 200) {
                myFunction(xmlhttp.responseText);
            }
        }
        xmlhttp.open("GET", url, true);
        xmlhttp.setRequestHeader("Authorization", 
                                 "Bearer {!$Api.Session_ID}");
        xmlhttp.send();

        function myFunction(response) {
            var res = JSON.parse(response);
            var d = document.getElementById('result');
            
            // iterate to the object keys 
            // and display the property values
            Object.keys(res).forEach(
                function(key,index) { 
                    //key = the name of the object key 
                    //index = the ordinal position of the key within the object 
                
                    d.innerHTML += "<strong>" + key + "</strong><br/>" + 
                                  "Max: " + res[key].Max + "<br/>" + 
                                  "Remaining: " + res[key].Remaining + 
                                  "<br/><br/>";
        
            });
        }
    </script>
    <div id="result">
    </div>
</apex:page>

I will not explain the code in detail but as a high level, we did an HTTP get using JavaScript XMLHttpRequest object to the REST url /services/data/<version>/limits/, passing our session Id to authenticate and then iterating over the list of information returned by the call.

The sample screenshot is below:


We can include a lot of of other improvements to the page like changing the look and feel so that it would look better and to retry retrieving the information on a timed interval. I hope this post have help anyone.

Happy coding!

12 April 2015

Using SoapUI to do SOAP calls to Salesforce

I've been involved on integration with Salesforce.com from and to other systems. One of the oldest protocol used on integrating with the system is using the SOAP protocol as it has a SOAP API that allows other systems to manipulate records. 

Personally, its worth while to have knowledge on how to consume the Salesforce SOAP method specially if you are working with an integrator who does not have prior experience integrating to Salesforce using the protocol. 

In the below examples I will be using SoapUI, an open source testing tool that supports not just SOAP but also other protocols such as REST and HTTP. I'll also be using the Salesforce partner wsdl but will provide alternative examples using the enterprise wsdl. For more information on the difference of the two, please take time to read this article.

The first thing to do is to download the Salesforce WSDL from Setup --> Develop --> API.


Once the WSDL is generated and download, we need to create a new SOAP project in SoapUI as depicted below.


Clicking the "Ok" will create the project as well as list the SOAP methods and samples (if "Create Request" checkbox is selected). Below is the generated project tree.


So let's starting creating our sample SOAP calls.

Partner login call

There are different ways of authenticating with Salesforce but for our example, we will use the login method that require to pass the user name and password to get a Session ID which is an encrypted value Salesforce pass back which is needed for succeeding calls.

Go to the login method from the SoapUI project tree and use or create a new request. Delete all of the values under <soapenv:Header> as we don't need to pass any value on the SOAP envelop. We will refer to this as the soap envelop header moving forward.

The request should be as follow (click here for the enterprise wsdl sample):


<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"     
     xmlns:urn="urn:partner.soap.sforce.com">
   <soapenv:Header>
   </soapenv:Header>
   <soapenv:Body>
      <urn:login>
         <urn:username>Salesforce User Name</urn:username>
         <urn:password>Password + security token</urn:password>
      </urn:login>
   </soapenv:Body>
</soapenv:Envelope>

From the request window, click the submit  icon to process the request. SoapUI will then attempt to do a SOAP call to Salesforce and returns a response below.


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns="urn:partner.soap.sforce.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Body>
      <loginResponse>
         <result>
            <metadataServerUrl>
              https://na5.salesforce.com/services/Soap/m/30.0/00D700000008fqn
            </metadataServerUrl>
            <passwordExpired>false</passwordExpired>
            <sandbox>false</sandbox>
            <serverUrl>
              https://na5.salesforce.com/services/Soap/u/30.0/00D700000008fqn
            </serverUrl>
            <sessionId>Session ID</sessionId>
            <userId>005700000012RyAAAU</userId>
            <userInfo>
               <accessibilityMode>false</accessibilityMode>
               <currencySymbol>$</currencySymbol>
               <orgAttachmentFileSizeLimit>5242880</orgAttachmentFileSizeLimit>
               <orgDefaultCurrencyIsoCode>USD</orgDefaultCurrencyIsoCode>
               <orgDisallowHtmlAttachments>false</orgDisallowHtmlAttachments>
               <orgHasPersonAccounts>true</orgHasPersonAccounts>
               <organizationId>00D700000008fqnEAA</organizationId>
               <organizationMultiCurrency>false</organizationMultiCurrency>
               <organizationName>REMOVED</organizationName>
               <profileId>00e70000000sEkZAAU</profileId>
               <roleId>00E70000000olJBEAY</roleId>
               <sessionSecondsValid>7200</sessionSecondsValid>
               <userDefaultCurrencyIsoCode xsi:nil="true"/>
               <userEmail>REMOVED</userEmail>
               <userFullName>REMOVED</userFullName>
               <userId>005700000012RyAAAU</userId>
               <userLanguage>en_US</userLanguage>
               <userLocale>en_US</userLocale>
               <userName>REMOVED</userName>
               <userTimeZone>America/Los_Angeles</userTimeZone>
               <userType>Standard</userType>
               <userUiSkin>Theme3</userUiSkin>
            </userInfo>
         </result>
      </loginResponse>
   </soapenv:Body>
</soapenv:Envelope>

Note that I have removed a couple of information from the response. However, the most important thing to note from the response is the Session ID and the ServerURL which we will used in our succeeding examples.

Our SoapUI should look like below:


Partner create call

Now that we have a Session ID and Server URL, we need to create a new request using the create method. Go to the create method from our project tree and use or create a new request. Delete all of the values soap envelop header except for <urn:SessionHeader> where we will need to add the Session ID value from the login call.

The request should be as follow (click here to see create call using enterprise wsdl):


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:urn="urn:partner.soap.sforce.com" 
    xmlns:urn1="urn:sobject.partner.soap.sforce.com">
   <soapenv:Header>
      <urn:SessionHeader>
         <urn:sessionId>Session ID from Login Call</urn:sessionId>
      </urn:SessionHeader>
   </soapenv:Header>
   <soapenv:Body>
      <urn:create >
         <urn:sObjects>
            <urn1:type>Account</urn1:type>
            <Name>Sample Account (Partner)</Name>
         </urn:sObjects>
      </urn:create>
   </soapenv:Body>
</soapenv:Envelope>

Note that we have manually typed the type node (represents the SObject type) and Name (which is the API name of the standard Name field) above for the request.

Before submitting the request, we also need to change the submit endpoint using the Server URL login response.



Below is the response from the create call.


<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"    
     xmlns="urn:partner.soap.sforce.com">
   <soapenv:Header>
      <LimitInfoHeader>
         <limitInfo>
            <current>2</current>
            <limit>15000</limit>
            <type>API REQUESTS</type>
         </limitInfo>
      </LimitInfoHeader>
   </soapenv:Header>
   <soapenv:Body>
      <createResponse>
         <result>
            <id>0017000001ExlcFAAR</id>
            <success>true</success>
         </result>
      </createResponse>
   </soapenv:Body>
</soapenv:Envelope>

Note that the <createResponse> node will have the result of the call. The <id> will contain the record Id for the record you are creating and the <success> will tell whether the call is successful or not.

The SoapUI should look like below:



Partner update call

Using the same Session ID, Server URL and the record Id from the create call, use or create a new update request from the SoapUI project tree and delete all the values from the soap envelop header except for the SessionHeader. The request should look as below (click here to see update call using enterprise WSDL):


<soapenv:Envelope 
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:urn="urn:partner.soap.sforce.com" 
    xmlns:urn1="urn:sobject.partner.soap.sforce.com">
   <soapenv:Header>
      <urn:SessionHeader>
         <urn:sessionId>Session ID from Login Call</urn:sessionId>
      </urn:SessionHeader>
   </soapenv:Header>
   <soapenv:Body>
      <urn:update>
         <!--Zero or more repetitions:-->
         <urn:sObjects>
            <urn1:type>Account</urn1:type>
            <Name>Sample Account (Partner) Updated</Name>
            <urn1:Id>0017000001ExlcFAAR</urn1:Id>
         </urn:sObjects>
      </urn:update>
   </soapenv:Body>
</soapenv:Envelope>


The response is below:


<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"    
     xmlns="urn:partner.soap.sforce.com">
   <soapenv:Header>
      <LimitInfoHeader>
         <limitInfo>
            <current>3</current>
            <limit>15000</limit>
            <type>API REQUESTS</type>
         </limitInfo>
      </LimitInfoHeader>
   </soapenv:Header>
   <soapenv:Body>
      <updateResponse>
         <result>
            <id>0017000001ExlcFAAR</id>
            <success>true</success>
         </result>
      </updateResponse>
   </soapenv:Body>
</soapenv:Envelope>

The SoapUI should look like below:





Partner upsert call

The upsert call is not much different with the update call except that there is an <externalIDFieldName> node that is required to have the API name of the field marked as external Id or the Id field. The field must be part of the request.

Below is the sample request using the same Session ID , Server URL and record Id which was used as the external id fr(click here to see update call using enterprise wsdl):


<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"  
     xmlns:urn="urn:partner.soap.sforce.com" 
     xmlns:urn1="urn:sobject.partner.soap.sforce.com">
   <soapenv:Header>
      <urn:SessionHeader>
         <urn:sessionId>0Session ID from Login Call</urn:sessionId>
      </urn:SessionHeader>
   </soapenv:Header>
   <soapenv:Body>
      <urn:upsert>
         <urn:externalIDFieldName>Id</urn:externalIDFieldName>
         <!--Zero or more repetitions:-->
         <urn:sObjects>
            <urn1:type>Account</urn1:type>
            <!--Zero or more repetitions:-->
            <Name>Sample Account (Partner) Upserted</Name>
            <Id>0017000001ExlcFAAR</Id>
         </urn:sObjects>
      </urn:upsert>
   </soapenv:Body>
</soapenv:Envelope>

Below is the response.

<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
     xmlns="urn:partner.soap.sforce.com">
   <soapenv:Header>
      <LimitInfoHeader>
         <limitInfo>
            <current>4</current>
            <limit>15000</limit>
            <type>API REQUESTS</type>
         </limitInfo>
      </LimitInfoHeader>
   </soapenv:Header>
   <soapenv:Body>
      <upsertResponse>
         <result>
            <created>false</created>
            <id>0017000001ExlcFAAR</id>
            <success>true</success>
         </result>
      </upsertResponse>
   </soapenv:Body>
</soapenv:Envelope>

Here is the SoapUI screenshot:



Most of the other SOAP methods follow the same request sample. However there are other functionalities such as running assignment rules, changing the debug log levels that are controlled via the envelop header.

Hopefully the example above can help anyone starting to learn integrating to Salesforce.com. :-)

Sample Salesforce SFDC Enterprise upsert

This is a sample SOAP Upsert using Enterprise WSDL. Note that we only passing the session Id  on the header information since we don't need the others and that the envelop must be posted to the ServerURL you got from the login call as per described in this blogpost. In addition, we need to put a value on the <externalIDFieldName> node with the field API name of the objects external Id. In this example, I used the Salesforce standard Id field.


<soapenv:Envelope 
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:urn="urn:enterprise.soap.sforce.com" 
    xmlns:urn1="urn:sobject.enterprise.soap.sforce.com"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Header>
      <urn:SessionHeader>
         <urn:sessionId>Session ID from login call</urn:sessionId>
      </urn:SessionHeader>
   </soapenv:Header>
   <soapenv:Body>
      <urn:upsert>
         <urn:externalIDFieldName>Id</urn:externalIDFieldName>
         <urn:sObjects xsi:type="Account">
            <Id>0017000001ExVRDAA3</Id>
            <Name>Sample Account (Enterprise) Upserted</Name>
         </urn:sObjects>
      </urn:upsert>
   </soapenv:Body>
</soapenv:Envelope>

Below is the sample SOAP response:

<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
     xmlns="urn:enterprise.soap.sforce.com">
   <soapenv:Header>
      <LimitInfoHeader>
         <limitInfo>
            <current>11</current>
            <limit>15000</limit>
            <type>API REQUESTS</type>
         </limitInfo>
      </LimitInfoHeader>
   </soapenv:Header>
   <soapenv:Body>
      <upsertResponse>
         <result>
            <created>false</created>
            <id>0017000001ExVRDAA3</id>
            <success>true</success>
         </result>
      </upsertResponse>
   </soapenv:Body>
</soapenv:Envelope>

NOTE:

The <createResponse> node will have the result of the call. The <id> will contain the record Id in SFDC for the record you are creating and the <success> will tell whether the call is successful or not.

*I noticed that SoapUI 5.0.0 does not automatically add the xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance". This is important when you are setting the object type <urn:sObjects> tag.

Sample Salesforce Enterprise SOAP update

This is a sample SOAP Update using Enterprise WSDL. Note that we only passing the session Id  on the header information since we don't need the others and that the envelop must be posted to the ServerURL you got from the login call as per described in this blogpost.


<soapenv:Envelope 
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:urn="urn:enterprise.soap.sforce.com" 
    xmlns:urn1="urn:sobject.enterprise.soap.sforce.com"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Header>
      <urn:SessionHeader>
         <urn:sessionId>Session ID from login call</urn:sessionId>
      </urn:SessionHeader>
   </soapenv:Header>
   <soapenv:Body>
      <urn:update>
         <urn:sObjects xsi:type="Account">
            <Id>0017000001ExVRDAA3</Id>
            <Name>Sample Account (Enterprise) Updated</Name>
         </urn:sObjects>
      </urn:update>
   </soapenv:Body>
</soapenv:Envelope>

Below is the sample SOAP response:


<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"      
     xmlns="urn:enterprise.soap.sforce.com">
   <soapenv:Header>
      <LimitInfoHeader>
         <limitInfo>
            <current>10</current>
            <limit>15000</limit>
            <type>API REQUESTS</type>
         </limitInfo>
      </LimitInfoHeader>
   </soapenv:Header>
   <soapenv:Body>
      <updateResponse>
         <result>
            <id>0017000001ExVRDAA3</id>
            <success>true</success>
         </result>
      </updateResponse>
   </soapenv:Body>
</soapenv:Envelope>

NOTE:

The <createResponse> node will have the result of the call. The <id> will contain the record Id in SFDC for the record you are creating and the <success> will tell whether the call is successful or not.

*I noticed that SoapUI 5.0.0 does not automatically add the xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance". This is important when you are setting the object type <urn:sObjects> tag.

Sample Salesforce Enterprise SOAP create

This is a sample SOAP Create using Enterprise WSDL. Note that we only passing the session Id  on the header information since we don't need the others and that the envelop must be posted to the ServerURL you got from the login call as per described in this blogpost.


<soapenv:Envelope 
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:urn="urn:enterprise.soap.sforce.com" 
    xmlns:urn1="urn:sobject.enterprise.soap.sforce.com"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Header>
      <urn:SessionHeader>
         <urn:sessionId>Session ID from login call</urn:sessionId>
      </urn:SessionHeader>
   </soapenv:Header>
   <soapenv:Body>
      <urn:create>
         <urn:sObjects xsi:type="Account">
            <Name>Sample Account (Enterprise)</Name>
         </urn:sObjects>
      </urn:create>
   </soapenv:Body>
</soapenv:Envelope>

Below is the sample SOAP response:


<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"    
     xmlns="urn:enterprise.soap.sforce.com">
   <soapenv:Header>
      <LimitInfoHeader>
         <limitInfo>
            <current>9</current>
            <limit>15000</limit>
            <type>API REQUESTS</type>
         </limitInfo>
      </LimitInfoHeader>
   </soapenv:Header>
   <soapenv:Body>
      <createResponse>
         <result>
            <id>0017000001ExVRDAA3</id>
            <success>true</success>
         </result>
      </createResponse>
   </soapenv:Body>
</soapenv:Envelope>

NOTE:

The <createResponse> node will have the result of the call. The <id> will contain the record Id in SFDC for the record you are creating and the <success> will tell whether the call is successful or not.

*I noticed that SoapUI 5.0.0 does not automatically add the xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance". This is important when you are setting the object type <urn:sObjects> tag.

Sample Salesforce Enterprise SOAP login

This is a sample SOAP Login using Enterprise WSDL. Note that we are not passing any header information here for the sake of example.


<soapenv:Envelope 
        xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:urn="urn:enterprise.soap.sforce.com">
   <soapenv:Header>
   </soapenv:Header>
   <soapenv:Body>
      <urn:login>
         <urn:username>replace this with our SFDC username</urn:username>
         <urn:password>password + security token</urn:password>
      </urn:login>
   </soapenv:Body>
</soapenv:Envelope>

Below is the sample SOAP response:


<soapenv:Envelope 
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
     xmlns="urn:partner.soap.sforce.com" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Body>
      <loginResponse>
         <result>
            <metadataServerUrl>
               https://na5.salesforce.com/services/Soap/m/30.0/00D700000008fqn
            </metadataServerUrl>
            <passwordExpired>false</passwordExpired>
            <sandbox>false</sandbox>
            <serverUrl>
              https://na5.salesforce.com/services/Soap/u/30.0/00D700000008fqn
             </serverUrl>
            <sessionId>REMOVED</sessionId>
            <userId>005700000012RyAAAU</userId>
            <userInfo>
               <accessibilityMode>false</accessibilityMode>
               <currencySymbol>$</currencySymbol>
               <orgAttachmentFileSizeLimit>5242880</orgAttachmentFileSizeLimit>
               <orgDefaultCurrencyIsoCode>USD</orgDefaultCurrencyIsoCode>
               <orgDisallowHtmlAttachments>false</orgDisallowHtmlAttachments>
               <orgHasPersonAccounts>true</orgHasPersonAccounts>
               <organizationId>00D700000008fqnEAA</organizationId>
               <organizationMultiCurrency>false</organizationMultiCurrency>
               <organizationName>REMOVED</organizationName>
               <profileId>00e70000000sEkZAAU</profileId>
               <roleId>00E70000000olJBEAY</roleId>
               <sessionSecondsValid>7200</sessionSecondsValid>
               <userDefaultCurrencyIsoCode xsi:nil="true"/>
               <userEmail>REMOVED/userEmail>
               <userFullName>REMOVED</userFullName>
               <userId>005700000012RyAAAU</userId>
               <userLanguage>en_US</userLanguage>
               <userLocale>en_US</userLocale>
               <userName>REMOVED</userName>
               <userTimeZone>America/Los_Angeles</userTimeZone>
               <userType>Standard</userType>
               <userUiSkin>Theme3</userUiSkin>
            </userInfo>
         </result>
      </loginResponse>
   </soapenv:Body>
</soapenv:Envelope>

NOTE:

The following is important on your succeeding calls using SOAP
  • sessionId: This is the value you would need to pass to succeeding SOAP calls as this proves that you are authenticated.
  • serverUrl:  This will be the URL you will need to post succeeding SOAP calls.
please see my blogpost for doing SOAP integration using Partner WSDL.


05 January 2015

Service Cloud Certification Tips

I have taken the Salesforce Service Cloud certification exam last October and luckily passed. It was a difficult one though even though I have experience using the module so I want to share tips on the topics that I remember part of the exam I took which I think everyone should review when taking the exam.


  • Call Center KPI reports. There were scenario based questions which would require to determine which metrics/reports best to use. I have used this link as starting point to be familiar with the common reports.
  • Visual Workflow. There were questions on the use cases of using Visual Workflow. Interestingly, I didn't encounter any questions regarding its component types which was suggested by all of the blogs I read regarding the exam.
  • Data Migration of Knowledge Articles. There are questions that specifically asked for the steps and fields to take care when migrating on-premise Knowledge Base to Salesforce Knowledge Base.
  • Data Categories. There are questions for the use-cases of using data categories and how best to assign articles access to users using data category using role or profile.
  • Implementation improvements of contact center. There are scenario based questions on how to lessen cost of maintenance of contact center, how to can enforce adherence to company goal like allowing customers to get support via all channel supported by Salesforce using any service cloud functionality.
  • Entitlement Management. There are questions related to entitlement management and the model it supports. (e.g. Entitlement Only, Service Contract with Entitlements, Service Contracts with line items and entitlement). 
  • Salesforce Console for Service. There are tricky questions about the old agent console and new Salesforce Console.
  • Implementation scenario for call using CTI versus open CTI.
  • Benefits of using KCS around case management module.
  • Email-to-case versus On-demand Email-to-case.
In my opinion, the best way to pass the exam is to read thru the topics listed on the exam study guide. Working on sample configuration from the service cloud workbook would greatly also help since you will get familiar on the process and configuration needed to enable and use the service cloud features.