4. This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties
materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results
expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be
deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other
financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any
statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our
services.
The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new
functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in
our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of
any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate,
our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new
releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization
and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of
salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form
10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings
section of the Investor Information section of our Web site.
Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently
available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based
upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-
looking statements.
Forward-Looking Statement
Statement under the Private Securities Litigation Reform Act of 1995
7. The Use Case
Clayton
Salesforce Code Analysis
The code assistant for Salesforce that
automatically finds security and quality
problems in your code.
• Founded by CTA Lorenzo Frattini (@lofrattini)
• Scans code automatically and detect issues during
development
• 10.2 billion lines reviewed and counting
• Salesforce DX ready
• getclayton.com
Clayton Data + Einstein Analytics = Hidden Insights
8. How did I get at it?
Lunch
And grilled them for
questions to ask their data
Got Data
Data hand over meeting
discussing their data model
Data Analysis
Look over Relational Data
Model + dataflow samples
Dashboard Build
Build the structure and first
widgets to showcase back
Show & Tell + Questions
Show the first stab at the
dashboard + ask questions
BUILD!
Continue dataflow and
dashboard build
1 2 3
4 5 6
Rikke Hovgaard – EA SA with Salesforce – Product – based in London
Joined about a year ago, but worked as a consultant with implementation partner
Worked with EA for about 4 years – experience also include core and MC and Pardot
Find me on twitter, linkedin or my blog
Raise your hand if you have heard of Salesforce Wave.
--
Well, it’s not a name you need to know anymore as it’s now called Einstein Analytics, however, it has changed a lot since it was introduced – in fact with every release it becomes more powerful with every release.
So Einstein Analytics is our advanced analysis platform. We generate all this data in Salesforce and other systems and we want to get insight, know how well we are doing or not doing. You can create reports in Salesforce but those reports are static – you don’t really explore them and often you see people export the data in order to do further transformation of the data in excel. Einstein Analytics allow you to get that same informantion but the dashboards are not static – you can explore the data and drill down into the questions.
Now this generally answers what happened and perhaps with a little bit of digging you can delude why it happened. But Einstein Analytics have an additional tool to leverage – Einstein Discovery, which gives us narrative explanations to what, why, what might happened and what you can do about it. Now in this section I will show you more of the building aspect, so Discovery is another session.
Before we get to building let’s just cover some basic things. We split the build up into two parts, but we should always thing of them as depending on each other. So never dig into one area without thinking about how it will affect the other.
Data layer is where we manage our data – doh. We can bring our data in from Salesforce in our data sync, we can connect to other data sources with our connectors – we flatten the relational structure and perform different transformation to our data in our data recipe or dataflow. In other words This is the place where the dataset building happens. And in order to build any dashboards in Einstein Analytics we need datasets.
Design layer is where we bring our data to life. It’s where we build dashboards by adding steps and widgets to tell a data story to our users. All our dashboards are saved in app, which is similar to a dashboard folder in Salesforce.
With this overview of Einstein Analytics covered let’s have a look at the use case.
Please raise your hand if you consider yourself a Salesforce Admin or Developer – someone who configure and build custom applications in Salesforce.
--- I figured there would be a few of you. And I hope that you with this use case not only learn what Einstein Analytics can do, but also some insight into general Salesforce development and typical issues in your Salesforce code.
Let me take a step back in time. I think about 3 years ago I was talking to my friend and colleague at that time Lorenzo Frattini. Lorenzo is a certified TA and we were working for the same Salesforce consultancy in London. We even sat next to each other in the office and lived in the same part of London – that’s pretty irrelevant, but one day we were chatting I think about documentation and he said “Rikke, you should start a blog about Einstein Analytics”. I gave it some thought and a year later I wrote my first blog. Now last year, circumstances would that we both resigned within weeks of each other. Lorenzo decided it was time to focus full time on his project and code analysis solution Clayton. I had a plan of going contracting, so while I was wondering “what am I gonna do to pay my rent” we met for lunch. Lorenzo told me of Clayton, how you can setup different rules of best practice that your code should follow, you then submit your code for a code review and based on the rule different issues will be araised, a clever tool in making sure your code is up to the best standards. I of course with this overview came to discover he has a loooot of data. We came up with an idea to do analysis on the analysis data. I started at Salesforce and that idea was great but forgotten. Until this year at London World Tour. So for the past 2 weeks I’ve been digging into his data and that’s what we will be looking at today.
I thought it might be interesting to know how we proceeded with this idea. Now ideally we would do a full blown workshop to figure out what made sense, but this is a pet project that has fit in with my other work.
First thing is we had lunch. I asked who is the audience, which was a developer. I then went on to asking what questions would they have. We jolted a few down like what is the top issues in code. Knowing if it’s security or visualforice that comes up often allows for them to know where the team need to put focus or maybe that’s where there need to be allocated more time for testing.
Next we discussed the data, where it was stored, how I could get access to it. It was all in AWS Postgres, so I knew we could leverage our connectors.
With that we went away – Lorenzo and team Clayton needed to copy there database and of course anonymize the data. A few days later it was ready and we had a data hand-over call. They had written a document explaining the key objects including the ERD data model. They even gave me a few query examples for me to understand the data structure. This proved extremely helpful. Every time I had little free time I did some build – I even build some of the dataflow while waiting for my flight to board.
We had a few follow up calls and email exchange for me to double check the data model and get some feedback.
Show dashboard
Click on customer type
Click on severity
Compare with end-user
High resolution time - could it be because of project complexity
Show action – see embedded dashboard
MOBILE? If created.
Move to data layer
Explain how we get data in from different sources.
Show connector
Show how to proceed with building CREATE SIMPLE DATAFLOW
Show the full dataflow
Move to design layer
Show pre-build not complete dashboard CLEAN IT UP
Build resolution time
Build custom map (severity on issues DS)
Have the issue over time by category ready
Build static step (GET API NAMES)
Do binding {{column(static_1.selection, [\”value\”]).asObject()}}
Add page w/ details
Show actions
Show embedding incl filter