I participated in the Summer of Hacks in NYC this past weekend. I wasn’t expecting to pitch an idea myself, but when they opened the mic for participants to speak to the group, I raised my hand and walked on to the stage.
“This is a Fitbit,” I declared to the room while holding up the tiny, bluetooth connected device. “It measures the amount of steps you take in a day. It then sends that data to your phone, which then sends it to the cloud. The consulting firm Appirio has said that they were able to save $300,000 in insurance costs by giving all their employees a Fitbit and starting a company-wide fitness program.”
“The app that I’m proposing will be that fitness app for your company. I want to build a Fitbit integration for Salesforce.”
And that is exactly what we did.
The truth is that we had started a similar fitness program at Silverline last year by also giving out Fitbits to our employees. It was a starter project from our new employees as they were learning the Salesforce platform.
I was very excited for the program, and volunteered to be a team leader for about five other employees. But that enthusiasm was crushed the moment I found out exactly how we were going to use the platform with our new wearables.
We would have to manually enter our steps every day into the Salesforce platform.
“But the data is already there online,” I protested. “Why can’t we just pull the data from the Fitbit servers?”
“Because we can’t dedicate any developer hours to this project,” said the newbie, “and nobody has time to do it themselves.”
He did have a point there.
Ever since then I had been craving to create a legitimate Fitbit integration and now I had a whole weekend to do it.
I signed up for a Fitbit API key and discovered that they used OAuth version authentication. I then hit the jackpot by discovering an open-sourced package by Heroku’s Jesper Joergensen called the SFDC OAuth Playground. I forked the repo, installed it to a new dev org, entered my Fitbit API keys to the Services tab, and like magic, I was able to authenticate to Fitbit and get data into Salesforce.
The Get Activities API call seemed to be the best place to get my information, particularly in the “summery” JSON object.
So I created a Fitbit_Day__c custom object to store the following data:
Lightly Active Minutes
Fairly Active Minutes
Very Active Minutes
I figure that should be enough for a proper integration. I created the Fitbit_Callout class to do the API callout and upsert the data to Fitbit_Day__c, then created a Fitbit_Batch class to find every linked user and run the callout on them.
So all the data was in the system and the integration was working great, but there was still something missing…
There we go. After running the batch, I had Chatter give out mad props to the user that had the most steps. And after racking up over 15,000 steps on Saturday, that winner was me when we finished on Sunday.
For the most part, that is all I did for the app over the weekend. My teammates – both of whom had never touched the Salesforce platform before – contributed to the project by working on the front end and creating dashboard and reports to analyze that data.
We didn’t place that weekend, but a number of the judges had said that they liked the idea and wished to actually deploy the app in their org some day. So I will continue to develop it into a full application, and I will write about the progress on this blog.
If you are interested in playing with the app yourself and maybe contributing to it, check out the Github repo. It is not production ready yet, but it should work.
Scott is a Certified Advanced Developer with 6 years Salesforce experience. Scott has helped companies of all sizes run their business better by designing customized business applications on the Force.com platform, creating and maintaining apps sold on the Salesforce AppExchange, and coordinating data flow between Salesforce and external systems by using API’s and third-party integration tools.