February 2017 – lekkimworld.com

Salesforce week 15

A week with two days of travel although not going to Stockholm for a change. This weeks trip brought me to Amsterdam and our Regional Kickoff for the EMEA North region. First day was breakout sessions for the various divisions and then drinks and dinner. Day 2 was the main regional kickoff and after a mindfulness session and group massage we got started. All good fun, good information an a nice place to meet new people and colleagues. Only drawback was the hallways of the venue where the noice levels from hallway conversations really made you tired. All in all two great days with the extended team. Wednesday, Thursday and Friday was either in the home office or at the office in Hellerup. All in all a normal week – but then again not quite…

Tuesday night I joined a conference call heading home from the airport. The conference call was on the pilot program on Salesforce DX which is the new Salesforce Developer Experience. If you are working with Salesforce and haven’t heard or seen anything about Salesforce DX you have work to do. Start at the before mentioned link and then see this session (Deep Dive Into The New Salesforce Development Experience (DX) Architecture) from Dreamforce 2016 showing what it is all about.

It. Is. So. Cool!

Let me give you a bit of backstory as to why. As you may know I didn’t join Salesforce until 3,5 months ago (15 November 2016) so I’m still new to the platform. What baffled me and was about to make me pull my hair out is the fact that the *org* is the source of truth for everything. Data and code. This means that all development and customizations are done in the org using the tools provided by Salesforce. The tools are okay but the workflow is just so old school compared to moderns toolchains and workflows. Salesforce DX turns all this on its head. With Salesforce DX development is source-first, the main way you interact with Salesforce is through the CLI (command line interface) which makes scriptning easy and orgs is something you create and throw away very easily (using scratch orgs). It. Is. So. Cool.

I’ve now had the pleasure to work with Salesforce DX for two days and it is just plain awesome. I’m already using it for some prototyping for the customer I’m working for and it’s just plain awesome. I can easily control my code using git and create different prototypes in branches and easily deploy to scratch orgs for testing. So nice. I’ll definitely be blogging more about Salesforce DX when I get an official “go ahead”. It’s a public pilot but want to air on the side of caution. Say tuned.

What did I learn

Salesforce DX rulez the day!
The gym at Hilton in Amsterdam can make most gyms jealous
Lightning grows more potent by the day
Did I mention Salesforce DX rulez the day?!

Status after this week

Trailhead points: 74000

Trailhead badges: 75

Certifications: 5 (Salesforce Certified Administrator, Salesforce Certified Platform App Builder, Salesforce Certified Advanced Administrator, Salesforce Certified Sales Cloud Consultant, Salesforce Certified Service Cloud Consultant)

Salesforce week 14

Short week as I had Thursday and Friday off – or PTO as we call vacation. But a great week. Monday and Tuesday I spent on-site in Stockholm and Monday night I finally got my act together and took the final certification exam of my onboarding and I’m very happy to report that I passed. Yay!! I now have passed all the 5 certifications I needed to pass. #happyDays

It was also my first week of being billable at the customer which was great. Wednesday was spent in the home office. All good stuff!

A thing I find myself doing more of is explaining the Salesforce fundamentals to people internally. Whether the job role is Success Manager, Account Executive, Project Manager or so on we (us at Salesforce) basically all have a requirement to pass at least the test for Salesforce Certified Administrator. This of course yields loads of questions from non-technical people as they simply do not have the same basic understanding of core fundamentals and a skeleton to hang their knowledge on if you will. So I’m using my ability to explain some of these things in very simple terms and answer questions. This is something I really like and I find that I learn more about the platform by having to explain it to people.

What did I learn

If you doubt whether you can pass an exam go for it!
You learn a lot by teaching a platform
There is some joy to actually being billable

Status after this week

Trailhead points: 71150

Trailhead badges: 72

Certifications: 5 (Salesforce Certified Administrator, Salesforce Certified Platform App Builder, Salesforce Certified Advanced Administrator, Salesforce Certified Sales Cloud Consultant, Salesforce Certified Service Cloud Consultant)

Salesforce week 13

Last week I spent two days at the customer site in Stockholm and 3 days at home in the home office. I think. Cannot really remember. Maybe I was in the office one of the days. Oh well 🙂 It’s starting to become normal to go to Stockholm and family life and work life is starting to work out. It seems like it will work for us. Customer project wise I almost finished the Lightning Component I’ve been working on for the customer and even made small changes to also make it work in Salesforce1. With both the web UI and the mobile UI being based off the same technologies make that pretty easy to do. Of course there are still things to address but they are mainly to do with the inherit difference in how users work on mobile vs on a desktop.

I actually thought I was done with the component last week but then I realized that writing test cases are required to deploy code into Salesforce. An org code coverage percentage of 75% is required. So this week I’m going to write the test cases for the server side controllers (written in Apex). One of the things which has been fun is that it’s very different writing code for production release than writing for the sandboxes or exercises I’ve been doing otherwise. For one normal coding practices like documentation and comments are way more important but also things which is less obvious start rearing its head. Security for one… I suddenly had to stop and consider object and record access for the custom objects I use for the solution. For this solution it wasn’t a big issue but one of those things that isn’t necessarily required for a PoC / sandbox implementation.

I’ve also started to figure out how to bundle up my solution into “something” I can deploy easily across the various orgs we use at the customer. For now it’s a bit of a kludge using the Apache Ant functionality by Salesforce. It will lukily become way better soon then new Salesforce DX approach become publicly available. If you do not know what Salesforce DX is stay tuned but in short it will turn the whole Salesforce development experience on its head. From the org being the source of truth to being based on a source-first approach so that your source repository becomes the source of truth and all development and deployment runs from the source to the org and not the other way. It looks very promising.

What did I learn

The Salesforce Ant extensions are fine to work with but still feels like a bit of a kludge
There are CLI extensions for Salesforce but they are not really ready for production use
Salesforce DX looks to be the solution I’ve been looking for
There is a difference between developing for a sandbox and a production org – remember to write those test cases

Status after this week

Trailhead points: 71150

Trailhead badges: 72

Certifications: 4 (Salesforce Certified Administrator, Salesforce Certified Platform App Builder, Salesforce Certified Advanced Administrator, Salesforce Certified Sales Cloud Consultant)

Salesforce for Newcomers – Introduction to orgs, sandboxes, API login and Salesforce security

As I venture into the Salesforce Universe myself there are many areas that I would have wished had been easier to figure out. So what better than remedying that with a series of blog posts. Maybe there will be one post and maybe more. We’ll see… This first instalment is on some of the basics in Salesforce namely the org, sandboxes and some of the security implications of logging in. I’m pretty technical so some of this will be from a technical angle so please forgive me and stay with me.

“Org”

When you get provisioned a Salesforce instance – or an org as we like to call them – you get your own slice of the Salesforce infrastructure. Depending on the amount of data you add to the org the slice may be VERY small or VERY big but the core concept is the same. Every org has an identifier (the “org id”) and that is what identifies it and the associated data throughout the Salesforce infrastructure. Everything you do in your org – data and customizations belongs to your org due to being coupled to your org id.

Boom! That’s it.

Sandboxes

A sandbox is something you may or may not get depending on the license types you buy and depending on the type of licenses you may even get more than one. Sandboxes are play areas that are connected to your org and allows you to develop and test customizations and – maybe – eventually move these customizations to your production org. Sandboxes come in different flavours and may contain no actual production data, some data or all of your production data. We call these empty, partial and full sandboxes. A sandbox always contains the customizations from the org it was generated from.

Besides the customizations a sandbox also gets a copy of all the users from the “source org” although the email addresses of users are changed in the process by removing the @-sign and appending @example.com. Bringing all the users across means that users may log into the sandbox using their existing username and password – the only change they need to do is to append a period and the name of the sandbox. So if my username is jdoe@acme.com and I’m logging into a sandbox called “uat” I simply use the username jdoe@acme.com.uat and my password.

Customizations may be moved between a sandbox and an org using a “change set” which basically is our way to move customizations between environments. There are other ways as well for more advanced uses but let us keep it simple for now.

Logging in

At Salesforce our number one value is trust. The trust of our customers and the trust they place in us to keep the data they entrust with us safe. This means we spend a considerable amount of time and resources keeping data secure and ensuring that no two orgs get mixed up. It also means that Salesforce offers a number of ways to make sure only the right people may log in and do that at the right time of the day.

These security features come in a number of flavors including but not limited to:

Username and password (duh!) and being able to set the complexity required of passwords.
Whether two factor authentication is required using either the Salesforce Authenticator app, login codes texted to your cell phone or emailed to you.
Which users may log in from what IP ranges and at what time of the day. If a user is assigned to a call center chances are they should only login from the call center location between 9am and 6pm.
What IP ranges are deemed trusted. A login from a trusted IP range is special in that it doesn’t require a second factor of authentication (that is besides username and password).

Besides these there are loads of other security mechanisms – way too many to dive into here in detail. If interested head over to Help & Training or get friendly with the security related pages under Setup in an org.

Security and the API’s

Authenticating to the various API’s for Salesforce is slightly different from logging in to the web UI or Salesforce1 (our mobile app). As a developer, you need to know the type of org (production or sandbox) you’re working against If you need to authenticate using the API’s. The main reason is due to any login IP restrictions you may have configured for your production org but really it’s not important to know why. Simply remember that when using API’s and you need to log into a production org you use login.salesforce.com and If logging in against a sandbox you use test.salesforce.com.

It’s that simple. Use test.salesforce.com for – well – testing. So if using OAuth and logging in to a production org you use https://login.salesforce.com/services/oauth/token and If logging in against a sandbox use https://test.salesforce.com/services/oauth/token.

And really that’s all there is to it.

Security Tokens

This is the final piece for this post but an important one. Remember those IP ranges that may have been set up as trusted in your org? If not go back and find that section and read it again… Salesforce uses the security token as a second factor of authentication if you are attempting to login from a source that Salesforce doesn’t not quite trust. For interactive logins the second factor is either a code from Salesforce Authenticator or similar but for API logins the second factor is your “Security Token”.

Think of the security token as:

An extra password that Salesforce issues to you (you cannot set it manually)
That gets reset whenever you change your password
Which is only ever revealed to you once. If you lose it, you may reset it from your personal Settings at which point the new one gets revealed to you.

Using the security token is very easy – you just append it to your actual password and use the resulting string as you normally would the password. As a super password if you will.

If you are lucky enough to be a developer and log into Salesforce using the API’s the security token is important to you as you may need to use your password/security token combo instead of your actual password. Again only if logging in from an untrusted network range such as when working from home without VPN or from Stackbucks.

For more information from the authoritative source of all things Salesforce I recommend reading through the posted titled Security and the API.

Lightning Components as Quick Actions in Salesforce1 and padding

Since Winter 17 we have had the option of using a Using Lightning Component as a Quick Action. In the Lightning Experience in a desktop browser the component is shown as a popup (actually a lightbox) in the UI and in Salesforce1 (the Salesforce mobile app) it’s more of a modal fullscreen dialog. All this is great. Only thing you have to do is to make your component implement force:lightningQuickAction (all declaratively) and it can be added as a Quick Action. The resulting lightbox / dialog will have a header with the action name and a default Cancel button to close the dialog. Again great but what if you want to name the button something else? Or if you need a custom header? Well there is another interface for this called force:lightningQuickActionWithoutHeader. So far so good. The issue is that while this removes the default header and buttons it doesn’t quite cut it in Salesforce1 as the container will still add a default margin around the component. Bummer…

The only way I found to fix this in the component I’m doing now is to add a negative martin on the component itself thereby hacking the UI. The added style is in bold – there is a negative margin to push the UI out of bounds to appear at 0,0 and a width and a height to make sure the header bar looks correctly. I’ve reported this internally and I hope someone will come up with a fix e.g. a new interface to add this explicitly.

<aura:component implements="force:hasRecordId,force:lightningQuickActionWithoutHeader">
    style="margin: -20px 0 0 -20px; width: 120%; height: 50px">
        
            Back
        
        Contact Sync
    
    
        UI body...
    
</aura:component>

Salesforce Platform Cache

Stumbled over the Salesforce Platform Cache the other day and just discovered this nice Trailhead Module on it (Platform Cache Basics). Worth 30 minutes if you’re developing on the platform.

Salesforce week 12

Week 12 brought me to Stockholm for 3 days, had 1 day in our new shiny Salesforce office in Hellerup (closer to Copenhagen center) and 1 day working from home. I spent most of the week getting up to speed on Salesforce Lightning and developing mockups for a custom component for the customer. All in all it was a great week where I learned a lot and made significant contribution to the customer project although I’m not officially assigned and billable yet (I’m shadowing).

Salesforce Lightning components are very nice and the component framework is cool although it is also pretty obvious in some areas that it’s new and there are round edges to be considered. Custom Lightning Components can be used in many places but unfortunately there are still areas where they cannot be used so workarounds are needed. Also building custom components can both be done from the supplied Lightning UI widgets and custom markup. For now most of what I’m doing resorts to combining custom markup with Salesforce Lightning Design System (SLDS) – I will have to see how much can and should be done using the built in components.

Much more to learn in the time to come.

Sunday it was time for Super Bowl and my New England Patriots came from behind to overcome a 25 deficit to win by 6 in overtime. What a great game!! Not much sleep but there is always coffee 🙂

What did I learn

Lots about Salesforce Lightning, Lightning Component and the Salesforce Lightning Design System (SLDS)
There are wicked many CSS classes in SLDS
Stockholm is a nice city
Patriots performed the biggest ever comeback in NFL history to close a 25 points gap to win by 6 in overtime

Status after this week

Trailhead points: 70400

Trailhead badges: 70

Certifications: 4 (Salesforce Certified Administrator, Salesforce Certified Platform App Builder, Salesforce Certified Advanced Administrator, Salesforce Certified Sales Cloud Consultant)