If you’ve heard of Salesforce’s 1-1-1 model you know that we pledge to leverage our resources, technology, and employees to help communities around the world. This comes in obvious ways, such as free licenses for non-profits, pro bono work, and employees volunteering literally one million hours. It also manifests itself in more surprising ways, like giving money to charity for riding your bike to work.
Since 2008 the Foundation has given $165,000 to a variety of non-profits as a direct result of employees cycling to work. Simply by logging their earth-friendly commutes in our platform employees can earn money for charity.
This year a total of $40,000 will be split among The National Cycling Charity, Cycle For Survival, the International Mountain Bike Association, the Leukemia & Lymphoma Society, Make A Wish Foundation, the San Francisco Bicycle Coalition education fund, the National MS Society, and the SF AIDS Foundation
What’s the problem?
Even though it’s for a great cause, consistently tracking your rides can be tiresome. Our current logging tool is just a form on a Visualforce page in a separate Foundation org. This means users need to switch to a different environment to enter a few pieces of data each week. It’s a repetitive task and it’s easy to forget to do, especially if you wait until Friday afternoon to log your week’s rides.
In addition, in the past the grants were given to a single charity which left some riders wishing their rides would impact an organization they were more excited about.
In short, it’s easier to not log your rides than it is to enter them. I used my PTOn time to integrate with Strava in order to make it impossible to forget.
Enter PTOn
Salesforce gives engineers a chance to work outside of the box with their time. Instead of PTO (paid time off) you get PTOn! (paid time on), where you work on any project that interests you and will help you develop new skills you may not get to use in your day job.
I work in the Customer-Centric Engineering organization, which means the majority of my time is spent troubleshooting issues and developing debugging tools. PTOn! gave me a unique chance to shift my focus to developing on the platform. Not only did this help me gain new skills, it provided me with a fresh perspective on the challenges customers may encounter when doing the same.
I ride my bike to work every day (racking up a measly 1,100 miles in a year) and always track my miles, so I wanted to make it easier for others to do the same. I had three demands for the upgraded app:
-
Employees have some choice of which charity receives their grant
-
Users can do it from their phone
-
Riders don’t need to remember to do it
The first part was easy. A few custom fields here and there and a user poll to select charities means this year’s grant will be divided across 8 great international charities based on the total distance contributed to each.
The last two problems are where the magic happens.
Someone else can do it for me
Instead of trying to reinvent the wheel I opted to go with the existing solution of Strava, which has a great mobile app for logging bike rides. You simply open the app and hit ‘Record’. You ride your bike to your destination and hit ‘Finish’. GPS does the work of calculating the distance and speed, and Strava keeps your ride information on their end. They have all the information I need on their end.
Best of all, people were already using the app.
Within three weeks of this integration being released, Strava accounted for over a third of new miles being logged in the Foundation.
And the cool part is that the number is still growing.
All that was left after making this decision was pulling that data into Salesforce.
But Strava isn’t part of Salesforce!
The meat of the project was to find the best way to bring data from Strava into Salesforce using their API.
After considering the options the API presented for getting the data, I came to the decision to have riders individually authorize their accounts using OAuth.
I created a Strava application that users needed to authorize to access their public activities, similar to how you might authorize a game to access your Facebook account so it can spam your friends when your raspberries are ready for harvest. This is a one time event and our platform can then automatically fetch rides without any further work by the end user.
The final result is the following:
-
A scheduled Apex job with some HTTP callouts to a remote site pointed at Strava’s API endpoint.
-
Access tokens stored in restricted fields (in the future will be moved to encrypted objects for additional security).
-
Data collected in JSON format, parsed using some inner classes that reflect the data structure, then inserted into custom objects in Salesforce.
In Salesforce, we keep the activity ID from Strava to prevent duplicates and also look back in time to allow bulk collection. This is handy for riders who track their commutes via a separate GPS app, such as Garmin, then import them into Strava at the end of the week.
After initial setup, the riders no longer have to navigate to our Foundation org and remember how many miles they rode each day. Exact totals are fetched within 24 hours of entering them into Strava.
Great for Learning
Since this was the first time developing anything of substance on the platform, my workflow looked a little bit like this for a while:
One example that stands out was when I was writing the JSON parser to handle the API response from Strava. I was banging my head against the wall trying to figure out how to handle the nodes properly since the activities don’t necessarily include all the same fields. I finally found the right docs about the Apex JSONParser class. I defined a custom inner class (Activity) with the fields I wanted to read and ended up handling the parsing as easily as this:
And because I was deploying into one of our production orgs where it could potentially impact our 20,000 employees and the Foundation operations, the admins were extra strict about my code. I learned our best practices for scheduled jobs, remote sites, making web callouts, optimizing SOQL and DML statements, ensuring bulk safety, keeping data secure, and of course how to effectively test all of this.
Connecting to Strava was a great success, but there’s more to be done. I’m preparing to connect with even more fitness trackers and working to improve the mobile usability for non-Strava users by building an app with our Lightning tools. Thanks to PTOn! I have a chance to keep learning as I build awesome tools for the rest of the company that I wouldn’t normally have had the opportunity to do.
Want to work on cool projects, both for your job and in addition to it? Salesforce is hiring! Visit http://www.salesforce.com/tech to find your #dreamjob.