28 July 2015

Who stole the cookie from the cookie jar?

Sample Visualforce Page using Google Charting API
Have you ever needed to track what users view, not just what they change? Have you ever had security, risk, or legal ask for a report on user activity for audit or regulatory reasons? Have you ever needed to track user's actions down to the device level so that activity on the phone, tablet, and web desktop are tracked separately?

Starting with the Summer '15 release, we're introducing key data leakage detection information through a pilot program. The goal of the pilot is to enable customers to query specific data leakage use cases in near real-time for analysis purposes.

The initial pilot of the Data Leakage Detection pilot tracks SOQL queries in near real-time from the SOAP, REST, and Bulk APIs. Because greater than half of all data accessed on the platform is performed via these APIs, organizations can gain greater insights into:

  • Who saw what data
  • When they saw that data
  • Where they accessed the data
  • What fields they accessed
  • How long a query took
  • How many records they accessed

When combined with the Login Forensics pilot, you can also track every query back to a unique login to identify anomalies in user behavior.

Each event consists of key information about the API transaction including:

  • AdditionalInfo
  • ApiType
  • ApiVersion
  • Client
  • ElapsedTime
  • EventTime
  • Id
  • LoginHistoryId
  • ObjectType
  • Operation
  • RowsProcessed
  • Soql
  • SourceIp
  • UserAgent
  • UserId
  • Username

This means you can find out who (e.g. Username), saw what (e.g. Soql) including sensitive PII (Personally Identifiable Information) fields, how much (e.g. RowsProcessed), how long (e.g. ElapsedTime), when (e.g. EventTime), how (e.g. UserAgent), and from where (e.g. SourceIp). Plus, you can correlate all of this information back to the original Login (e.g. LoginHistoryId) to profile user behavior and disambiguate between legitimate and questionable activity beyond the login.

Once the pilot is enabled in your organization, you can visualize a set of events using the sample Visualforce page with Google Charting API from my Github repository.

To learn more specifics about the Data Leakage Detection Pilot functionality, read the pilot tip sheet and to participate in the pilot, please contact your account executive or customer support rep.

13 July 2015

Track your Apex limits in production using Apex Limit Events

Salesforce Apex is the backbone of the programmatic platform. With it you can push the customization of any org beyond the button click realm.

Example of an app you can build with the
Apex Limit Events Pilot
Apex runs in a multitenant environment. The Apex runtime engine strictly enforces limits to ensure that runaway Apex doesn’t monopolize shared resources. If some Apex code ever exceeds a limit, the associated governor issues a run-time exception that cannot be handled. Apex limits are defined in the Salesforce documentation.

I wrote about tracking Apex limits in a blog post last May (That which doesn't limit us makes us stronger). As a force.com developer, you have the ability to instrument your Apex code with System.Limits() methods that allow you to compare how much you're using against the ceiling of what's allowed by any limit.

However, the more instrumentation you add, the more opportunity you have for code and performance issues. It's the Heisenberg concept - that which you try to measure affects the measurement. And even when you do try to track limits in this fashion, the results are stored in developer oriented tools like the Debug Logs or the Force.com Console logs which are really only meant to be used in sandbox. Bu what about DevOps? How can they monitor the health of their developer's code in production?

As a reaction to this, we are introducing the Apex Limit Events pilot program in Summer '15.  The goal of this pilot is to enable operations to monitor their production instances in near real-time and with automated hourly roll-up aggregate metrics that tell you the state and health of your Apex according to their limits.

Each event consists of key information about the Apex execution in the context of a limit including:
  • EntryPointId
  • EntryPointName
  • EntryPointType
  • EventTime
  • ExecutionIdentifier
  • Id
  • LimitType
  • LimitValue
  • NamespacePrefix
  • UserId
  • Username
Each hourly metric consists of key aggregate information including:
  • Distinct Number of Apex Transactions
  • Distinct Number of Apex Transactions With Limits Exceeding 60% Threshold
  • Distinct Number of Apex Transactions With Limits Exceeding 60% Threshold By Entry Point Name
  • Distinct Number of Apex Transactions With Limits Exceeding 60% Threshold By Limit Type
  • Average Limit Value By Entry Point Name
  • Average Limit Value By Limit Type
Apex limit events is accessible via the Salesforce public API through the apexlimitevent sobject. The only user interface is an org preference in setup that an administrator can control to enable or disable the feature within their org.

To help developers and operations bootstrap their efforts to take advantage of this feature, I built a Github repo including a:

1. Visualforce page and tab integrating Apex limit events with the Google Charting API
2. LimitsTest Apex class that exposes a REST API webservice you can use to intentionally exceed limits and load data into the apexlimitevents sobject
3. ApexLimitJob Apex class that can be used with scheduled Apex to generate limits
4. limitsHammer python code that makes it easy to generate limits data

To participate in the pilot, contact salesforce support or your account executive. For more information about the pilot, check out the tip sheet.

09 June 2015

The Salesforce Hacker Way

This post is dedicated to the innovation exchange students who visited Salesforce on their recent tour of Silicon Valley companies. Innovation exchange is a summer program offered by my alma mater, James Madison University (JMU).

As JMU alumni, a couple of us here at Salesforce hosted a question and answer session for the students in this program. The panel members came from product, engineering, design, and analyst relations.

The students came prepared with a set of great questions like:

  • How do you know when you have enough product to launch?
  • How do you know when to kill a product?
  • How do you take an idea to market?
  • How is Salesforce different from Dropbox?
  • Who competes with Salesforce?
  • How do you get a job out of college?

We shared our perspective about what it means to work as a team building products that customers love. We talked about ideas like launch vehicles (e.g. pilots vs betas), about getting the right people in the design room early, and about our experiences getting our first jobs out of college as well as the meandering path that led us all to Salesforce.

It was a great session and it got me thinking about sharing some fundamental product guidelines that I call the Salesforce Hacker way (in priority order because I'm a product manager and that's just how I roll):

  • Have faith. Not faith in the religious sense of the word but instead faith in yourself and your team. Otherwise, how will your ideas survive the dark night of other people telling you to work on other priorities first?
  • Figure out what's most important. When stack ranking ten stories, there's the first priority and then there's everything else. And whatever you choose, someone will tell you it is wrong. See rule one. Rob Woollen, former SVP of platform, gave this tip to me.
  • People over technology every time. Creating new products using new technologies like BigData for the Internet of Things use cases using Agile methodology with Full Stack developers may win you a game of engineering bingo. But if it doesn't solve real people's problems, what good is it? It's like a tree falling in the forest and no one being around to hear it.
  • Always be listening. Sales has their mantra, 'always be closing'. But for product, it's listening. Incidentally, when people say they are good listeners, they're talking, not listening. Listening is a skill everyone needs to develop; even those people who think they're good at it. 
  • Fail fast, fail often, fail spectacularly. Fear of failure blocks innovation. Learning from failure enables the next product to be better. Make sure your product organization supports your ability to fail as much as your ability to succeed. One of my best learning experiences came from a product that never launched leading to my next product being a success.
  • Complex designs lead to simple user experiences, simple designs lead to complex user experiences. How can you scope, constrain, and deliver the minimal amount of product necessary to trade customer value for feedback. The best feedback comes from less product, not more. I got this gem from the venerable Craig Villamor during a PTOn project a couple of years back. PTOn is where you take time out to work on a project that is not necessarily related to your current goals or team objectives.
  • Iterate, iterate, iterate. The longer a product stays in design or development, the bigger the chance of it never launching. Iterating enables a feedback loop from customers which will influence a roadmap of enhancements. 
  • Change takes courage. Designing and delivering a product may mean changing someone's concept of how things currently work. Treat that transition with respect and find ways to overcome the fear that comes with any change.
  • Stay calm, especially when everyone else isn't. This one is pure psychology. When stressed, our fight or flight reflex takes over. But what if there was a third option? When everyone else is stressed, a calm voice of reason can diffuse almost any situation.
  • You'd be amazed at what a smile and question can accomplish. Seems silly but keep in mind that everyone in the product lifecycle will protect resources, over estimate time or effort, and challenge ideas or priorities. These are actually good things to have in a product lifecycle. So keep smiling and don't be afraid to ask a clarifying question. My favorite starts with, 'why...?' and usually ends with, 'if you had this product, what would you actually do with it.' 
  • Transparency and honesty is critical. If your not willing to communicate via a banner trailing in the sky behind a plane, then you need to question what you're saying and to whom.
  • The size of an opportunity is directly proportional to the size of the problem. Keep looking for ways to disrupt people's mindsets and be ready to embrace it when it comes. 
  • Momentum is not the same as inertia. Never dismiss the power of momentum or how hard it is to start building a product. Never mistake inertia for forward progress. Products die sooner from inertia but get built with the right amount of momentum. 
  • Written specs are out of date as soon as the first person reads them. Requirements come from the tests and the documentation comes from the code. Everything else is a well articulated conversation between partners who have taken ownership of an idea.
  • Have Fun. Building product isn't easy but it is a lot of fun. If it's not fun, find a new job.
  • Come up with ten impossible ideas everyday. This exercise reminds me about possibilities in the face of compromise and even the basic laws of physics. This exercise actually originated in Alice in Wonderland.
I don't really expect anyone, including the students I met last week, to follow any of these guidelines. In some situations, I don't even follow all of them. That's why they're called guidelines.

It took me a long time to learn them through a set of experiences and challenges that culminated in successful products that I'm truly proud of. Many of these guidelines are inherited, borrowed, and stolen from the incredible people I work with on a daily basis. But if you work with product or aspire to build incredible products one day and you don't have any framework already, you might find some minimally viable goodness in these words. And from their, iterate, iterate, iterate.

That's the Salesforce Hacker way.