How to Translate Salesforce Custom Labels Cheat Sheet

Custom Labels are custom text values that can be accessed from Apex classes, Visualforce pages, or Lightning Web Components and allow developers to build multilingual applications to provide a localized user experience.

We have a more detailed guide on localization with Salesforce Custom Labels, but below is an easy cheat sheet covering the basic mechanics. You’ll learn how to easily translate all Custom Labels from any application into a new language, whether translating with Google Translate, like below or through a human translator.

Salesforce Custom Label Translation Cheat Sheet

1. First, on your org code directory, go to src/labels to download CustomLabels.labels. Now go to src/translations to download the most current and complete translated language, for instance, fr.translation.

2. Rename both files as .xml.

3. Open MS Excel (at least 2007 version) and select the Developer tab. Go to XML, click on Import button and select the CustomLabels.xml file.

4. Delete all columns except ns1:fullName and ns1:value.

5. Filter column ns1:fullName with Contains Labels.

6. Select columns ns1:fullName and ns1:value (and its rows), then go to Find & Select. Go to Special, select checkbox Visible cells only, and then click the Ok button.

Now you can copy only the rows that are displayed within the filter.

7. Open Google Docs and choose the Blank Sheet option.

8. Paste copied rows directly into the Google Sheet.

9. Select all columns, then go to Data->Sort Range and select to order first by ns1:fullName and second by ns1:value. We have to do this because we need at least one of the label columns to be sorted so that when we are looping through the other set of data, we are sure we are looping all possible labels.

10. Add a new header to ja.translation.xml file, name it Translation. Add in the first cell =GoogleTranslate (<ns1:value cell>, “en”, <CodLeng>). For example: =GoogleTranslate(B2, “en”, “ja”), then copy or drag the cell until all the rows have been translated.

11. Copy all Google Sheet columns and paste them at the left of the Excel sheet fr.translation.xlsx like this:

12. Add a column in which we will match label cells hence the translation) from both tables with this formula: =VLOOKUP($G2;$A$1:$C$1 91;3;FALSE). The $ character is used to fix a column or a row depending on its placement. (If it is before the letter, that column will be fixed despite copying the formula to other columns. If it is before the number, you are fixing the row.)

  • $G2 is the first cell from the right dataset which contains the first custom label name and will loop through $A$1 up to $A$191 (in this example), searching to match labels.
  • The range ($A$1:$C$191) is fixing the column and row of the left set of data.
  • 3” indicates which value from the range of data we would like to copy when there is a match in the search, in this case, it will be doing so from the Translation column.
  • FALSE” forces that the formula only retrieves a match by exactly matching the label names.

13. Delete those cells where the formula returns #NA (meaning, there was no match between label names).

14. Where a translation was returned, replace the right dataset cell from column ns1:label with this value.

15. Once done, delete the left dataset (A to C columns) as seen in the above screenshot leaving ns1:label as Column A.

IMPORTANT: ns1:label2 and ns1:name3 are created for custom tabs values. We need to translate these, save the translation somewhere else and delete them from ja.translations.xlsx. 

We will later add them to the ja.translations.xml this way:

<customTabs>
 <label></label> 
 <name>DocumentLibrary</name>
</customTabs> 
<customTabs>
 <label></label>
 <name>Tasks</name> 
</customTabs>

16. Save the Excel sheet, go to Developer:

17. Click on Developer:

18. Click on Export and save the file as <CountryCode>.translation.xml.

19. Remove the .xml extension.

20. Add any customTabs deleted together with their translations as described in Step 15. 

And that’s it! Learn more from our team, or check out our services.

Salesforce Certification: Nonprofit Cloud Consultant

At Oktana, we are committed to Pledge 1%, an initiative founded by Salesforce that encourages companies to give back to their local communities. We’ve also worked with several nonprofit organizations for years, helping them integrate with Salesforce products.

What is Salesforce Nonprofit Cloud

Salesforce believes business should improve the state of the world, so shortly after the company was founded, they created a foundation now known as Salesforce.org. Over the years, Salesforce.org has directed effort to enable nonprofits and educational institutions with Salesforce solutions to meet their needs.

When Salesforce.org first moved down this path, they launched the Nonprofit Starter Pack (NPSP) which provided a basic set of functionality that made Salesforce more nonprofit “friendly.” With the Nonprofit Starter Pack, nonprofits could migrate their data and customize Salesforce to manage fundraising, donation management and satisfy a variety of other nonprofit use cases. In 2018, they took it to the next level and launched Salesforce Nonprofit Cloud.

Over the past few years, we have helped nonprofit organizations do everything from build full apps to implement custom communities. In 2020, we were accepted into the Salesforce.org Partner Program, a program many nonprofits rely on to integrate Salesforce products.

Part of the process of becoming a Salesforce.org partner required becoming certified on the Salesforce Nonprofit Cloud. We spoke with two members of our team, Lucas and Nery, on what it took to earn this consultant-level certification. They both happen to work in our Paraguay office and are passionate about giving back – throughout the COVID-19 pandemic Nery has 3D-printed face masks.

Salesforce Nonprofit Cloud Certification

The Basics

  • Being a Salesforce Certified Administrator is a prerequisite.
  • The certification enables you to design and implement solutions that are maintainable, scalable, and meet nonprofit business requirements.
  • Both Lucas and Nery agreed it takes approximately 3 to 4 months to prepare for the exam.

 

Nery, who is a developer, suggests you change your mindset from Admin to Cloud, grasping the bigger picture. Considering you already have your Admin knowledge as a base, you primarily need to focus your study on the nonprofit-specific functionality of Salesforce Nonprofit Cloud. He recommends reviewing the permissions and import/export rules because this can be confusing at first. 

Lucas offers additional advice. As a QA engineer, he considers it important to understand very well the table of triggers that work with the Success Package. For each of the packages Salesforce offers, there are external roadmaps that help you learn the specifics and give you detailed information that can help you pass the exam. This certification doesn’t need code, it is only about managing the platform efficiently and effectively.

They both agree this certification greatly helps when working with a nonprofit organization. Salesforce Nonprofit Cloud provides very practical solutions to manage grants, organize volunteer hours, implement forms that can be integrated into volunteer communities and many other functionalities.

How Nonprofits use Salesforce

We recently helped a nonprofit organization build a community platform focused on empowering breast cancer patients with resources for diagnosis, treatment and recovery. The goal of the platform was to guide patients along their journey, facilitating connection between individual patients and health providers. Built on Salesforce, you can read the complete story.

Should you become a Salesforce Nonprofit Cloud Consultant?

If you are already a Salesforce Certified Administrator, the Nonprofit Cloud Consultant certification will provide a more specialized Salesforce career path. If you are interested in working with nonprofit organizations, you should definitely consider this path. 

Here is a list of some resources that will help you out:

If you are part of our team, Oktana will provide you with some extra resources to help you successfully pass the exam and continue to develop your career with Salesforce. If you’re interested in joining our team, check out Oktana Careers.

 

 

Test Automation & Continuous Integration with Salesforce DX

Meet the Salesforce Developer Experience, Salesforce DX

Salesforce DX provides you with an integrated, end-to-end lifecycle designed for high-performance agile development. Learn how to integrate the Salesforce DX with automation framework and Jenkins to automate testing and achieve continuous integration.

Before you get started

Ensure you have these things set up so you can follow the steps of this module:

If you’ve completed the App Development with Salesforce DX Trailhead module, likely you already have the tools you need to complete this module. If you’re unsure, we recommend heading over to Trailhead first.

What is Continuous Integration?

Continuous integration (CI) is a software development best practice. When using CI, all code that development teams produce is merged into a central repository, where an automated build can validate it. This practice helps development teams detect problems, identify bugs, and allows them to fix them before releasing changes to their customers.

CI is like an insurance policy. Would you risk driving around town without car insurance? No way! In today’s world of agile development, it’s easy to push changes to your orgs. With a CI system in place, even the smallest change is processed to ensure your system continues to work flawlessly. Early detection and fixes are key for happy software stakeholders.

So now you know that CI can help your company save money. Next, we’re going to walk you through the steps to set up CI with Salesforce DX.

Continuous Integration with Salesforce DX

When using automation, it is preferable to create a disposable environment (like a scratch org) to test specific code/changes instead of introducing these changes to a shared org. Salesforce CLI allows you to automate the creation of scratch orgs as part of your CI process. Another cool feature is that Salesforce CLI enables you to completely script all these tasks in the CI configuration file whether you are using org-based or package-based development.

What is a Salesforce scratch org?

A scratch org is a dedicated, fully configurable, and short-term Salesforce environment. 

It allows developers to emulate different Salesforce editions with different features and preferences playing a critical role in development productivity and collaboration. They can also be used as part of automation testing and the implementation of a full CI suite.

It is possible to share the scratch org configuration file with other team members, so everyone can have the same basic org.

Scratch orgs increase developer’s productivity and collaboration during the development process, and facilitate automated testing and continuous integration. You can use the CLI or IDE to open your scratch org in a browser without logging in.

Note: If you try to just install the Salesforce CLI and run Salesforce DX commands, you’ll find quite a few commands will first need you to authenticate into a Dev Hub. This functionality is what allows you and your team to create and manage scratch orgs.

What is a Salesforce Dev Hub?

A Dev Hub provides you and your team with the ability to create and manage scratch orgs. Scratch orgs are temporary Salesforce environments where you do the bulk development work in this new source-driven development paradigm.

To get started with scratch orgs, you choose an org to function as your Dev Hub. While you can enable Dev Hub in any paid org, it’s always best to practice somewhere other than production. Instead, go ahead and enable Dev Hub in a Developer Edition org or Trailhead Playground to use with this module.

  • Can be your Dev or Prod Org.
  • Used to manage/track Scratch Orgs.
  • Link Namespaces to your orgs.
  • Create and manage second-generation packages
  • Is disabled by default. Once enabled, can’t be disabled.

Understanding the Salesforce Development Process

Diagram of Salesforce development process: Org based vs. source/package development
  • Org based model, in which as the name indicates, orgs are the source of truth. Almost the same as the previous models but this time changes are developed and released through Ant migration, metadata API deploy and retrieve.
  • Source/Package development, which is SalesforceDX’s way of development, we are going to use the new scratch orgs in which changes are developed using Salesforce DX CLI (source push/pull commands) and are then released using Metadata API Deploy. In this case we switch from Org Based to Source based, this way our source of truth is going to be our VCS i.e github, bitbucket, assembla.

It is important to note that instead of the traditional Org based development model, where development is done in sandbox/developer orgs then source code is pulled from such orgs to be stored in the metadata API format, a package based development model is recommended using the Salesforce DX project and scratch orgs. 

That being said, moving away from the org-based development model doesn’t mean that you don’t need proper environment management, it’s just the developers’ org that are replaced with scratch orgs. Integration and QA testing is also done in scratch orgs while the validation, testing, and UAT continues to happen in their dedicated sandboxes. In this scenario we may still want to use DevPro Sandboxes to perform some types of testing like Load testing.

Let’s get started!

Let’s go through our preconditions:

  1. Install Salesforce DX – CLI (using NPM):
    • npm install sfdx-cli –global
    • sfdx –version
    • sfdx –help
    • sfdx force:auth:web:login -d -a DevHub (Used to login to your DevHub)
    • sfdx force:project:create -n MyProject –template standard (to create an standard clean SFDX project)
  2. Enable your DevHub:
    • Log into your Org.
    • Setup > Search Dev Hub
    • Enable Dev Hub!
    • Dev Hub available in: Developer, Enterprise, Performance, and Unlimited Editions.
  3. Start Creating Scratch Orgs:
    • Define your project-scratch-def.json file
    • sfdx force:org:create -f project-scratch-def.json –set default username (to create a scratch org based on your `definition` file.
    • sfdx force:org:list (to list all your linked dev hub and scratch orgs)
    • sfdx force:org:display (to display data of your scratch org)
    • sfdx force:source:push (to push code to the org)
    • sfdx force:source:pull (to pull code from the org)

Note: On project-scratch-def.json, probably the most important file to start with for scratch orgs it this. Here we can define what the shape of the scratch org is. Whether we want to enable chatter, or lightning or multi-currency, usually you login, go to setup and enable all those, here we can define all the different preferences and features we want on our scratch.

Jenkins Setup

Jenkins is an open-source, extensible automation server for implementing continuous integration and continuous delivery. You can easily integrate Salesforce DX into the Jenkins framework to automate Salesforce applications testing against scratch orgs.

To integrate Jenkins, we assume:

  • You are familiar with how Jenkins works. You can configure and use Jenkins in many ways. We focus on integrating Salesforce DX into Jenkins multibranch pipelines.
  • The computer in which the Jenkins server is running has access to your version control system and to the repository that contains your Salesforce application.

Before integrating your Dev Hub and scratch orgs into your existing Jenkins framework, configure your Jenkins environment. Our example assumes that you’re working in a package development model.

  1. In your Dev Hub org, create a connected app as described by the JWT-based authorization flow. This step includes obtaining or creating a private key and digital certificate.
    Make a note of your consumer key (sometimes called a client ID) when you save the connected app. You need the consumer key to set up your Jenkins environment. Also have available the private key file used to sign the digital certificate.
  2. On the computer that’s running the Jenkins server, do the following:
    • Download and install Salesforce CLI.
    • Set the following variables in your Jenkins environment by going to Credentials > Select your project folder > Global Credentials > Add New Credentials:
      1. HUB_ORG (DevHub username ID) – Kind: Secret Text
      2. CONNECTED_APP_CONSUMER_KEY – Kind: Secret Text
      3. JWT_KEY_FILE – Kind: Secret File  
      4. Repo access credentials (GitHub Username and Password)
    • The names for these environment variables are just suggestions. You can use any name as long as you specify it in the Jenkinsfile/Build process.
      You can also optionally set the SFDX_AUTOUPDATE_DISABLE variable to true to disable auto-update of Salesforce CLI. CLI auto-update can interfere with the execution of a Jenkins job.
  3. (Optional) Install the Custom Tools Plugin into your Jenkins console, and create a custom tool that references Salesforce CLI. The Jenkins walkthrough assumes that you created a custom tool named toolbelt in the /usr/local/bin directory, which is the directory in which Salesforce CLI is installed.

Jenkins Build

Now we have to specify on Jenkins the steps needed to build our project, create our scratch orgs and run our tests:

  • On your Jenkins project > Click Configure 
  • Add your repository credentials on Source Code Management section:
  • Set build triggers:
    • For CI, Jenkins should be triggered every time a change is merged to your branch (H / 5 * * * * means it will pull changes every 5 minutes)
  • Enable Xvfb so jenkins can run graphic interfaces (for UI tests):
  • Bind your previously created environment variables:
  • Set Custom tools (Salesforce DX previously installed).
  • Provide Node and NPM if needed.
  • Add a build step:
    • Execute Shell:
  • Add post-build steps if needed, we will use junit and allure reports on this:
  • Click Apply/Save button
  • Go to your project and click the Build Now button
    • It will start building your project following the steps you specified on the ‘Execute Shell’ window.
    • You can open the execution console and see the progress
    • If you added post build steps they will be executed accordingly.

That’s it!

If you followed all the steps you should be able to run your Salesforce DX Project, Automation framework, and Jenkins to automate testing and achieve Continuous Integration!

Learn more about Salesforce development from our team, or check out our testing services.

API Testing with the Karate Framework

This article has two goals. The first is to find interesting information about API Testing with Karate. The second is to help you discover how interesting test automation is and dive deeper into the knowledge behind the passionate job of testing.

And why testing and not Quality Assurance? In this topic, I follow Michael Bolton when he says “Testers: Get Out of the Quality Assurance Business” Words matter and this is a matter of expectations management: we cannot promise something we cannot accomplish.

Michael Bolton

The Forgotten Layer of the Test Automation Pyramid

When we think and design a testing strategy we should not forget The Forgotten Layer of the Test Automation Pyramid: The service layer.

Here is where we need to mention the test automation pyramid. This concept is introduced by Mike Cohn in his book Succeeding with Agile.

He describes three levels of test automation, their relationship, and their relative importance. The base layer consists of unit tests and the top layer corresponds to user interface-level tests.

Many times when we start testing without a proper strategy we end up doing the opposite: investing most of the time and the effort in UI tests, which are more expensive to develop and maintain than unit tests. Also we can forget to develop tests for the service level, that’s why they call it the forgotten layer.

As Joe Collantonio described some years ago now, API testing is becoming more and more important. So even if we agree or not with the test automation pyramid schema, it reminds us that we have to pay attention to API testing as part of our strategy.

Software Development Life Cycle

We’re into a spatial representation of the job. As we move down in the testing pyramid, the tests are cheaper, easier to develop, and can find issues in earlier stages, which makes them easier and cheaper to fix than in later stages.

This can be seen as moving left in the Software Development Life Cycle (SDLC), so many teams are involved in Shift Left Testing. Is that enough? It’s not, but it’s a really good move. Which is the next step? Continuous testing. Involve testing in every stage of the SDLC, doing it efficiently, doing it repeatedly, as part of the whole process.

Here is when selecting the right tools becomes important: a testing tool that can integrate with our CI (continuous integration)/CD (continuous delivery) systems is a great value.

API Testing Resources

As API testing becomes more and more important, we can find a lot of sites to help us learn more about it. I can suggest just a couple of them which I found very useful:

Learn more about the Karate framework

Why is Karate so attractive? Because it’s an open-source tool that combines API test-automation, mocks, performance-testing, and even UI automation into a single, unified testing framework.

Let’s take a look at some of the benefits:

  • Language neutral
  • Suitable for non-programmers
  • Elegant DSL syntax
  • Built on Cucumber / BDD Syntax
  • Integrates into existing CI/CD
  • Good documentation
  • Good demos

This Hello World example gives an idea of how simple yet powerful it is.

Peter Thomas provides a deeper explanation in his Webinar on Micro-services Testing With Karate.

I found really good arguments about how we can leverage the goods of Karate for our own project. Learn more in the following example: Karate, the black belt of HTTP API testing?.

Some points that look interesting are:

  • Tests = Documentation: tests are so easy to read that you can document your API with your tests. And as you have to maintain your tests as the API changes, you have your documentation always up to date.
  • Simple: Karate takes care of complexity so you don’t have to worry about Json processing as Karate takes care of that.
  • Re-use Karate tests in Gatling to do performance testing: having the power of Gatling based on the API tests you already have is a big win.
  • Comprehensive and detailed reports: Karate brings powerful and detailed reports that makes reading the status of our tests very easy. It’s also helpful to debug and troubleshoot problems when you get failures. If you add the benefit of Gatling reports it’s like having two superpowers.
  • Data Driven Testing: you can run your tests through tables.
  • Mocks fake HTTP servlet: you can execute your tests with a mock server that implements your API.

Karate vs Rest-assured

Do you need to decide which tool suits better for your needs?

Refer more about the following comparison here.

Extra sources about Karate API Testing

I found very useful the following example in Test Guild site.
You can also check this demo.

Conclusions

I found Karate can be a great option for automating the checks in the forgotten layer, integrating it in your CI/CD schema, also re-using your tests as the documentation of your API and for performance testing.

Is the right tool for you? It depends on your particular project, your needs, and your team. If you want to add the API testing to your strategy, you don’t have too much time and you want to make it simple, it seems like a great option.

Learn more from our team here, or check out our testing services.

Python and Salesforce

Today’s post is about, you guessed it, using Python and Salesforce together. Salesforce offers a few different REST API endpoints that allow us to interact with our org. They also offer a SOAP API, but we’re not going to use it today. In fact, we don’t need to worry about the endpoints at all. Thanks to a Python library called Simple-Salesforce.

 

We could do this all by hand with the built-in requests library. You would have to handle sessions, OAuth process and save tokens, deal with request headers, encoding and decoding JSON, creating configs to handle all the different endpoints, etc…

 

Simple-Salesforce Python Library

 

 

This is where the wonderful world of open source software comes to the rescue. A man named Nick Catalano created a library called simple-salesforce. From what I understand, he isn’t actively developing it anymore, but due to open source, the community has picked up adding features. It has about 50 contributors as of July 8, 2020. The lib is being actively developed, with new features added like bulk API support and formatted SOQL queries!

 

 

With a bit of the background out of the way, let’s start digging into the library and see what we can do with it. First, no better way to explain what simple-salesforce is than to quote the README itself:

 

Simple Salesforce is a basic Salesforce.com REST API client built for Python 3.3, 3.4, 3.5, and 3.6. The goal is to provide a very low-level interface to the REST Resource and APEX API, returning a dictionary of the API JSON response.

Simple Salesforce

 

In plain text this quote means Python 3.x is supported, REST requests are handled for us, and the data we want comes back as a native Python data type. Great! Just what we want.

 

Login Information

 

First up, we’ll need a few things from Salesforce. Three things to be exact. Our username (email), password, and security token. The username and password should be pretty easy to find in your profile settings in your Salesforce org, but where do we find the security token? We don’t really see it, rather we’ll need to reset it.

 

 

 

 

 

 

 

 

 

After clicking “Reset Security Token” , you should be sent an email containing your new token. Save this, we’ll need it in the next steps. That’s all we need from Salesforce to get up and running. Now that we have that, let’s start building our Python script and start playing with our org.

 

pip and pipenv

 

 

But first, a quick word about PIP. While working on this example, there was an update to simple-salesforce lib. Github has the current version and we need the format_soql method from it. But pip (PyPi) hasn’t been updated with the new version as of yet, July 2 2020. So, we’ll need to install it via it’s repo on Github.

 

pipenv install -e git+https://github.com/simple-salesforce/
simple-salesforce.git#egg=simple-salesforce

If you are using the demo repo I built, we won’t need to worry about the requirements or dependencies if using pipenv. The demo has a Pipfile that’s pulling from the repo already thanks to the magic of pipenv.

The code

Now, let’s write some code. First up, we’ll bring in the libs we’re going to use. The only one that is not part of the standard lib is simple-salesforce:

from simple_salesforce import Salesforce, format_soql
from pprint import pprint
import json

Simple enough, import simple-salesforce, pprint (pretty print), and json. pprint is only used to make the terminal output look better, so it’s not needed for the core examples. json is used to get the credentials from a .json file, which is what we’ll do next.

# open file holding our login information
# we have the login info in a separate file so we can
# add it to .gitignore to help prevent leaking the information
# environment variables could also work
with open("login.json", "r") as login_file:
    creds = json.load(login_file)

Keep credentials secret

If you were on a project working in a private repo and multiple people needed access to the login credentials, keeping login info in the script itself would be okay, not ideal but okay. The reason we’re doing it is because it’s good practice and it’s open to the public on Github. So hiding and not committing sensitive information is important. This goes for any language or code base.

With that disclaimer out of the way, I included an example login.json file called very creatively “EXAMPLE_login.json“. Let’s take a quick look at it.

{
    "login": {
        "username": "sfdemo@kbcarte.com",
        "password": "My-REALLY-amazing-password",
        "token": "kdjfghdgfFGJbDFgd36DFGHDfgh"
    }
}

Very simple json object only containing the three things we got from the last steps. You can just copy/paste the “EXAMPLE_login.json” and rename it to just “login.json“, then update it with your login information. You can do this in the file explorer or VSCode, but here’s a quick example to do it from the command line.

cp EXAMPLE_login.json login.json
vim login.json

Salesforce Object

With our new login information, we can create the salesforce object back in our python script.

sf = Salesforce(username=creds['login']['username'],
                password=creds['login']['password'],
                security_token=creds['login']['token'])

And that’s it! We now have an object that represents our org, and now we can start doing cool things like SOQL or DML. Next, since we have everything we need to start awesomeness, let’s try a simple SOQL query.

SOQL Query

# an example of running a simple SOQL query
SOQL = "SELECT Id, Email FROM Contact"
data = sf.query(SOQL)
for d in data['records']:
    pprint(f"{d['Id']} -- {d['Email']}")

We defined the query string to get the Id and Email from all the Contacts, called the query() method of our salesforce object, then looped through the returned records and display the results. A note to those new to Python, in the pprint() we use something called an f-string or format string. It makes it easier to embed variables in strings, much like the way Aura Components handle expressions with {!v.my_var}

SOQL is cool and all, but what about adding new data to our org? We can do that too, very easily. We’ll even try using the bulk api to insert 1,000 record. But first we need to create 1,000 records. This is going to be mock or fake data just for the sake of simplicity. We’ll also be testing on the Account object, so only thing required for new records is the Name field.

data = []
for i in range(0,1000):
    data.append({
        "Name": f"Bulk Test {i}"
    })

Now we have a list of dictionaries that represent our record data. Here we have a for loop filling a list with new items. We could also use list comprehension to replace these 5 lines of code with just one.

data = [{'Name': f"Bulk Test {i}"} for i in range(0, 1000)]

Bulk Insert

To bring these new records into Salesforce, we use the .insert() method for the object we want, coming from the salesforce object we created. Confused yet? Here’s the insert code, it should help make things more clear.

# insert the new account using the bulk api
x = sf.bulk.Account.insert(data, batch_size=10000, use_serial=True)
pprint(x)

Here, we’re telling our org we want to use the bulk api “sf.bulk“, then which record object we’re working with “.Account.“, and finally what we want to actually do “.insert()“. We could use any object too, doesn’t have to be just Account. Even custom objects work, so instead of where Account is, we can replace it with something like sf.bulk.MyCustomObj__c.insert(..... We can also specify the batch size, or to process in serial.

Bulk SOQL

If you visit your org and take a look at all Accounts, you should see 1,000 new accounts with names like “Bulk Test 42”. We can also try doing another SOQL query, this time we’ll use the bulk api for the query. We’ll also show how to use things such as “LIKE” in SOQL statements.

# now lets get those records so we can delete them
SOQL = format_soql("SELECT Id, Name FROM Account WHERE Name LIKE '{:like}%'", "Bulk Test")
the_accounts = sf.bulk.Account.query(SOQL)
pprint(the_accounts)

Simple-salesforce now comes with the handy little method called format_soql that allows us to do things such as LIKE. format_soql is also the reason we used the Github repo for pip instead of what’s on PyPi, the new method was just introduced in the last 2 weeks.

Now that we know we can insert and add new data and records to salesforce, let’s see about removing it. Looking at the README, seems like the delete() method needs a list of records containing the Id of the record to be deleted. The records need to be a key-value pairs or dictionary just like how the query was returned. We already have all the Id’s for our inserted record from the “bulk.query()

{'Id': '0013h00000EdP87AAF',
  'Name': 'Bulk Test 998',
  'attributes': {'type': 'Account',
                 'url': '/services/data/v42.0/sobjects/Account/0013h00000EdP87AAF'}}]

Looks like simple-salesforce also returns something called “attributes“. This just tells use which object we’re working with and which api endpoint we got the information from. For our example, and for the .delete() method, we only need the Ids. So let’s clean up and make a new list with only what we want.

account_ids = []
for a in the_accounts:
    account_ids.append({"Id": a["Id"]})
pprint(account_ids)

Here is another opportunity to practice list comprehension! See if you can get that for loop down to one line.

Bulk Delete

So now we have the list of Id’s, now we just simply call the delete() method and go refresh our org’s Account list.

data = sf.bulk.Account.delete(account_ids, batch_size=10000, use_serial=True)
pprint(data)

All the records we inserted are now gone!

Final Thoughts

In conclusion, let’s recap what we’ve learned. For one, Python is awesome. Second, integrating Salesforce in a Python project is very very simple. With only three pieces of information, we can create a native Python object representing our Salesforce org, do things with the object like SOQL and DML, and finally have access to multiple salesforce API such as bulk or search.

This is only scratching the surface. We can do much more and simple-salesforce also has methods for metadata and describe. From this basic example, we could bring in Salesforce data to Flask API’s we build or insert new data to Salesforce from a data scraping crawler we make in Python.

We can also harness the power of Python’s ecosystem of visualization and reporting such as Pandas or SciPy. Nothing stopping us from grabbing Salesforce data and running it through machine learning or neural networks using PyTorch or TensorFlow.

If you’ve made it this far, thanks for reading! Here I’ll link the demo repo containing all the code discussed in this post and a YouTube video of my presentation. Also, if you are interested in learning more about Python, you can check this article: How to do Time Series Analysis with Python & Pandas.

https://www.youtube.com/watch?v=rf1jx3jbL2M&feature=youtu.be

How we connected Salesforce and Slack

The Oktana team built a demo to share how Salesforce and Slack work together. Our team leader walks through how the team built a Node.js app on Heroku that connects to the Slack API and Sales Cloud. The app is capable of both reading and writing to Salesforce from Slack.

You can create and update Salesforce tasks without ever leaving Slack. If someone else updates or assigns a task to you in Salesforce you’ll get a notification alongside all your other Slack messages. Take a look and let us know if something like this might be a good fit for your company.

Hope you’ve found this full walkthrough useful and insightful. We are Salesforce platform experts and offer custom development to help you build your platform and solve the right problems. Our team has worked with different organizations and their projects. If you want to know more about our work, go check out our latest success stories.

App Development with Salesforce Technologies

Working together with our partners to bring ideas to life is one of the driving forces behind everything we do here at Oktana. That’s why when Huge approached us to help them with app development for Stanley Security; we leaped at the chance.

Stanley is a large security company specializing in commercial security systems. They needed a tool for their field sales team to use on the go that showcased their current product offerings. Also, they preferred to manage the process through the app, on either computers or tablets.

Huge has excellent skills in front-end development and was planning to develop the app and the UI/UX elements internally. But they needed a partner to help complete the backend work and sync everything up with Stanley’s Salesforce instance. That’s where the team at Oktana came in. Huge was able to focus on designing a front-end experience that would satisfy Stanley’s sales team. Meanwhile, Oktana could focus on a seamless experience on the back end.

How do the front and the back of this application work, and what did it take to make them play nicely? The front-end app was built utilizing React and Node.JS, managed with a Postgres database that Huge hosted on Heroku. For our backend development, we needed to make sure everything tied into the Postgres database correctly. To do that we utilized Heroku Connect to transfer between the front-end database and Salesforce. Additionally, we mapped all the data so that everything was stored where it needed to be on both ends of the application process. This application’s design was for interfacing with Stanley’s Salesforce organization, and it required a Salesforce login to access the app and all of its features. The login ensured that anyone using that app is a part of the sales team at Stanley. 

Now, beyond the basic connective functionality, we needed to complete all aspects of the sales cycle through this app. This included allowing the sales team to send emails for clients with sales details and other information. To make that happen, we built an email tool using Apex and Visualforce. Stanley also wanted to close sales within the app, so we built in Adobe Sign functionality. Sales contracts could be signed digitally, and Zuora payment systems facilitated immediate payment. The final step was to synch the new data with the Salesforce organization.

The key technologies used in this project include:

  • Salesforce
  • Heroku
  • Postgres
  • React
  • Node.JS
  • Heroku Connect
  • Apex
  • Visualforce
  • Adobe Sign
  • Zuora

This project allowed us to work collaboratively with another development team to build different parts of an app. We’ve been able to successfully demonstrate our skill and ability to understand other’s work and apply it to our goals.

We’re looking forward to working with both Huge and Stanley again in the future. If you have a project that we can help you with, please be sure to let us know!

Learn more from our team here, or check out our custom development services.

Connecting Salesforce and Slack

We’re always looking for new challenges here at Oktana. One recent challenge that presented itself to us came from our partners, a leading investment firm. This investment firm out of California works with growth-stage companies in a wide variety of industries. They approached Oktana to help them find a solution to an efficiency problem within their organization. The primary tool that they used within the organization for work was Slack, and several different apps designed to interface with it. Their employees had to switch between Salesforce and Slack to manage updates and new tasks that would populate through Salesforce.

That’s where Oktana came in; the firm wanted a way to integrate Salesforce into their Slack experience to help save everyone at their company time and energy while they’re working. What could we do to bring these two platforms together? We started by exploring what tools might already exist within Slack that would make this integration quick and easy and found Incoming Webhooks. With Incoming Webhooks, we were about to take any new notifications from the Salesforce org about new task assignments and send them to users within the Slack instance.

This implementation was a success, and users were receiving notifications, but it was apparent that it wasn’t going to be the right solution for the long term. There were severe limitations to what we could do with Incoming Webhooks. While it could bring in notifications from Salesforce, it wasn’t able to limit those notifications to those directly involved with the task and instead sent them indiscriminately to the entire team. Additionally, there was no way to talk back to Salesforce after you received a notification in Slack, Incoming Webhooks is a one-way street. As such, we decided that we would need to take a different approach to solve this problem.

Thankfully, our partners at the firm were receptive to these concerns and were open to our recommendation for another option that might better suit their long-term needs. Since Incoming Webhooks did not fit our needs, there was only one course of action to take at this point. We needed to build a bespoke app to do the job. We created a small application in Node.js hosted on Heroku that would handle everything the investment firm required and more.

First, the app would replicate the functionality of the old implementation and take any task notifications from Salesforce and send them to Slack. Next, the app acts as a chatbot on Slack that can receive messages from Slack and send them back to Salesforce to update and create new tasks. Additionally, we built this app to be as lightweight and efficient as possible. At its core, the app is always listening to both sides, and when it detects something relevant, it translates the message and sends it from one application to the other. Oktana development process is about creating the most value possible for our clients. The lightweight nature of the app means it has space to grow and take on other functions so that the link between Salesforce and Slack can be expanded later on if needed. The app also can interface with applications beyond Salesforce if the need were ever to present itself.

The Critical technologies from this project:

  • Salesforce
  • Slack
  • Node.js
  • Heroku
  • Apex
  • Incoming Webhooks

This project was about seeing disfunction in how employees at the investment firm were working and finding a way to make it more streamlined. We saw that our client needed a solution for fixing their workflow, and we were able to accurately identify the problems as well as the best way to solve them. Now, they don’t have to move between Salesforce and Slack every time they want to update tasks, and we were able to face a new challenge head-on and solve it creatively.


Gathering Leads with Royal Caribbean

At Oktana, we’re heavily invested in the world of mobile app development. We believe that building new mobile tools that let our customers interact with their Salesforce instance out in the field is essential to the future of the platform. One of the most recent projects that allowed us to utilize our Mobile development skills is our project with Royal Caribbean for their Celebrity Cruises premium brand.

Celebrity Cruises participates in a number of large conferences and expos every year where their sales team is out in the field talking to potential clients and customers. They needed a way to easily gather data from the people they met for giveaways and potential sales leads. Additionally, this needed to be a tool that would allow them to gather the data while offline and then sync with Salesforce when they reconnected later because while moving around at conferences they can’t count on network connectivity.

Oktana was brought in to build an iPad app that would accomplish these goals. The app was built and designed internally by us. We designed an app that was slick and would be impressive looking so that when potential customers saw it on the floor it would look like something you would expect from a premium brand like Celebrity Cruises. We needed to make sure it met all of the client’s needs from beginning to end which included both the technical aspects and the app’s appearance.

What tools did we use to accomplish this task? We built the app using Salesforce DX along with Forcereact and the Salesforce Mobile SDK. The app also talks directly to the Salesforce Sales and Marketing Clouds. When a member of the sales team at Celebrity Cruises is preparing to go out to the floor of a show or conference they simply need to launch the app and select the Salesforce campaign the leads will be entered into. Then when they disconnect from the network the app will store all their leads locally and when they reconnect to the network at the end of the day it will sync them with the proper campaign. Additionally, when leads are entered the team member has the option to edit them for errors or even delete them before they sync to keep their campaign list clean.

This project was a perfect fit for us because it allowed us to utilize our experience in mobile development and Salesforce to make a unique tool for our client. The key elements to highlight for this project include:

  • Salesforce DX
  • React Native
  • Salesforce Mobile SDK
  • Apex
  • Sales Cloud
  • Marketing Cloud
  • iOS
  • UI/UX Design

While we have been working on this project for Celebrity Cruises we have also been helping Royal Caribbean with ensuring their tools meet GDPR requirements in the EU. We created tools to ensure collected data could be anonymized upon request. Royal Caribbean has been a great partner for us at Oktana and we believe this app was a great showcase of our skills in both Salesforce and Mobile development.

If you are a Salesforce partner looking to partner with experts to help you provide the best custom app development solutions to your clients Contact us. Our team will give you more information about these services.