When Salesforce is life!

Author: Enrico Murru Page 6 of 20

[Salesforce] Dealing with the running User on Einstein Bot dialogs

 
As part of the Salesforce Solutions Team at WebResults I spend some time training myself on new products and trying to build POCs (prove of concepts) to give value to the training and promote the knowledge inside my company.

I recently was playing with Einstein Bots and got stuck when needed to identify the running user, when dealing with queries to get actual user info from the CRM.

I though it was enough to call the UserInfo.getUserId() method and I could get who is the user calling the bot, but unfortunately the running user of an Apex InvocableMethod is the AutomatedProcess user, that you can monitor from Setup > Debug Logs > User Trace Flags [New] as shown below:

I believe that Salesforce will add this feature in the next feature but I had to find a workaround.

The Workaround

I started a thread on Stackoverflow, where I got some ideas but no solution at all.

After a while I came up with a dirty solution that allowed me to know the exact user logged into the community. I won’t explain all the trial and errors but the whole solution, with some code samples.

Here is the list of actions:

  1. Enable Pre-Chat
  2. Override Pre-Chat with a Lightning Component
  3. The Pre-chat Lightning component calls its controller to get if there is a valid running user and returns back all the data needed for the prechat
  4. The Lightning component compiles all the needed inputs for the pre-chat (e.g. name, email and username) and submits for the chat: if the info are found, the component hides the pre-chat fields (that may be filled by a non authenticated user)
  5. The info submitted are written on the Transcript object
  6. An Einstein Bot dialog examines the Transcript object using an IncobaleMethod of an Apex class and determines which is the running user
  7. The bot can now change its behavior depending on the fact that the user is logged or not

To get all of this working you need 2 custom fields:

  • A custom field on the Contact/Lead record (we’ll call it Username__c) that is used to configure the prechat on the Snap-In
  • A custom field on the LiveChatTranscript object (we’ll call it Username__c as well) used to store the info got from the Pre-Chat component

Once fields are created, we need to setup the Pre-Chat page on the Snap-in settings related to the bot:

And setup the Pre-chat page:

Now let’s create the Lightning component that will replace the Snap-in chat (configured in the picture above):

prechat.cmp

For the what & whys plese refer to the official documentation in this link.

The component uses the lightningsnapin:prechatAPI that is needed to trigger the chat once the info are filled in.

<aura:component
    implements="lightningsnapin:prechatUI"
    controller="Bot_PreChatCmpCnt">
     
    <aura:attribute name="userId" access="PRIVATE" type="string" default="-"/>
    <aura:attribute name="firstName" access="PRIVATE" type="string" />
    <aura:attribute name="lastName" access="PRIVATE" type="string" />
    <aura:attribute name="email" access="PRIVATE" type="string" />
 
    <!-- Contains methods for getting pre-chat fields, starting a chat, and validating fields -->
    <lightningsnapin:prechatAPI aura:id="prechatAPI"/>
     
 
    <!-- After this component has rendered, call the controller's onRender function -->
    <aura:handler name="init" value="{!this}" action="{!c.doInit}"/>
     
    <aura:renderIf isTrue="{!empty(v.userId)}">
        <lightning:input type="text" value="{!v.firstName}" label="Name *">
        <lightning:input type="text" value="{!v.lastName}" label="Lastname *">
        <lightning:input type="text"  value="{!v.email}" label="Email *">
         
        <lightning:button label="Start chat!" onclick="{!c.onStartButtonClick}"/>
    </aura:renderIf>
</aura:component>

The list of input fields are only shown when the v.userId attribute is blank (you can note that it is initialized with “-“, and in the lightning controller is blanked only when no logged user is found).

prechatController.js

The controller calls the Apex controller to get the main user info: if they are found, the chat is started.

({
doInit: function(component, event, helper) {
        var action = component.get("c.getCurrentUser");
        action.setCallback(this, function(response) {
            var state = response.getState();
            if (state === "SUCCESS") {
                var result = JSON.parse(response.getReturnValue());
                console.log(result, embedded_svc);
                component.set('v.userId', result.userId);
                if(result.userId){
                    component.set('v.firstName', result.firstName);
                    component.set('v.lastName', result.lastName);
                    component.set('v.email', result.email);
                    helper.startChat(component, event, helper);
                }
            }else if (state === "ERROR") {
                var errors = response.getError();
                if (errors) {
                    if (errors[0] && errors[0].message) {
                        console.log("Error message: " +
                                 errors[0].message);
                    }
                } else {
                    console.log("Unknown error");
                }
            }
        });
        $A.enqueueAction(action);
    },
    onStartButtonClick: function(component, event, helper) {
        //handling errors
        if(!component.get('v.firstName')
          || !component.get('v.lastName')
           || !component.get('v.email')) return alert('Missing fields.');
        helper.startChat(component, event, helper);
    }
});

prechatHelper.js

The startChat() method compiles the array of fields to be passed to the chat plugin, that will start the chat with the Bot.

({
     
    startChat: function(component, event, helper){
        var fields = [
            {
                label: 'FirstName',
                name: 'FirstName',
                value: component.get('v.firstName')
            } ,
            {
                label: 'LastName',
                name: 'LastName',
                value: component.get('v.lastName')
            }  ,
            {
                label: 'Email',
                name: 'Email',
                value: component.get('v.email')
            },{
                label: 'Username',
                name: 'Username__c',
                value: component.get('v.userId'),
            }
        ];
        if(component.find("prechatAPI").validateFields(fields).valid) {
            component.find("prechatAPI").startChat(fields);
        }
    }
});

prechatHelper.js

The Apex controller simply makes a query on the user object and considers it a loggedin user if the ContactId field is not null (but you can use your own conditions):

public class Bot_PreChatCmpCnt {
    @auraenabled
    public static String getCurrentUser(){
        Map<String,Object> output = new Map<String,Object>();
        User u = [Select Username, FirstName, LastName, Email, contactId From User Where Id = :UserInfo.getUserId()];
        if(u.ContactId != null){
            output.put('userId', u.UserName);
            output.put('firstName', u.FirstName);
            output.put('lastName', u.LastName);
            output.put('email', u.Email);
        }else{
            output.put('userId', '');
        }
        return JSON.serialize(output);
    }
}

That said we need to instruct the Pre-Chat plugin to write the fields on the LiveChatTranscript object, which is the only thing that grants the Bot’s dialogs to be aware of the running context. Create a new Static Resource and remember to set the Cache Control to Public.

embedded_svc.snippetSettingsFile.extraPrechatFormDetails = [
  { 
    "label":"Username", "transcriptFields":[ "Username__c" ],
  },{
    "label":"Cognome", "transcriptFields": ["LastName__c"]
  },{
   "label":"Nome", "transcriptFields": ["FirstName__c"]
  },{
   "label":"Email", "transcriptFields": ["Email__c"]
}];

This Static Resource must be configured in the Snap-in Component on the Community builder:

Einstein Bot Dialog Apex action

Last step, before configuring the bot, is to create a new Apex Class that will retrieve the users information coming from the current transcript:

public without sharing class Bot_GetSnapInsPreChatData {
    public class PrechatOutput{
        @InvocableVariable
        public String sFirstName;
        @InvocableVariable
        public String sLastName;
        @InvocableVariable
        public String sEmail;
        @InvocableVariable
        public String sContactID;
        @InvocableVariable
        public String sLoggedUser;
    }
    public class PrechatInput{
        @InvocableVariable
        public String sChatKey;
    }
    @InvocableMethod(label='Get SnapIns Prechat Data')
    public static List<PrechatOutput> getSnapInsPrechatData(List<PrechatInput> inputParameters)
    {
        System.debug('######## Input Parameters: '+inputParameters);
         
        String sChatKey = inputParameters[0].sChatKey;
        String sContactId = null;
        List outputParameters = new List();
        PrechatOutput outputParameter = new PrechatOutput();
        if (sChatKey != null && sChatKey != '')
        {
            List<LiveChatTranscript> transcripts = [SELECT Id, CaseId,
                                                    ContactId, Username__c
                                                    FROM LiveChatTranscript WHERE ChatKey = :sChatKey];
            if (transcripts.size()>0)
            {
                sContactId = transcripts[0].ContactId;
                outputParameter.sLoggedUser = transcripts[0].Username__c;
            }
        }
         
        if (sContactId != null && sContactId != '')
        {
            List<Contact> contacts = [SELECT Id, FirstName, LastName, Email, Username__c
                                      FROM Contact WHERE Id = :sContactId];
            if (contacts.size()>0)
            {
                outputParameter.sFirstName = contacts[0].FirstName;
                outputParameter.sLastName = contacts[0].LastName;
                outputParameter.sEmail = contacts[0].Email;
                outputParameter.sContactId = contacts[0].Id;
            }
        }
        outputParameters.add(outputParameter);
        return outputParameters;
    }
}

This class read the coming sChatKey value to query the LiveChatTranscript object that stores all the informations coming from the PreChat.

This LiveChatTranscript can be further manipulated to add more and more data for your context.

You must also define a hidden Bot variable containing the Live chat transcript key, that must be called LiveAgentSessionId (and is populated by the Live Agent engine automatically):

Now you can safely configure your dialog and be sure to know if the user is logged or not, and change the Bot behavior consequently:

[Salesforce / Release Management] YOU SHALL NOT PASS! (Unless you pass the Quality Gates)

 

What happens if, once you learned how to walk, you start to run?

Well, you might stumble and fall.

Depending on how well you react you might get a bruise or a bloody nose.

What happens if you have a tool that can increase the speed of your releases?

Well, you might run into some issues upon releases.

Depending on if you are using version control, you might recover your work or not.

But from a project management perspective the main question is:
How do I avoid stumbling, falling and having a discussion about delivery capabilities with project stakeholders (aka “those who pay the bills”)?

Starting from the running example, we probably stumble because we do not control the movement at some point. Maybe, because we did not practice walking long enough or because the floor was uneven and “surprised” us. In any case, it is because we lost control.

Believe it or not, it’s similar in software development: If you lose control over what happens in your process ( = movement) you can damage the product you deliver.

We have learned how to “walk” with Copado in the first post of this series, we outlined how all team members contribute to an efficient movement in the second one, and started to “run” in the third post.

So before we even come close to falling, let’s talk about how to maintain control and achieve reproducible and predictable release outcomes.

Our final goal is to achieve that German thing everyone once in a while mentions: Quality.
(Hehe, World Cup 2018, that will stick for a while)

Quality gates are not there to annoy – they are a safety net

Working with Copado and having a seamless integration with Git in the background, we avoid a worst case scenario (fall on your face and damp the hit with your forehead) as we always have a way to roll back to a stable version.

But the process we introduced also contains two review points, which is something no release process should miss:

  • A review of your developments from a technical perspective by a peer or a lead developer. This will ideally prevent devs from introducing sketchy solutions and you get to keep your job.
  • A review of your developments from an end user perspective (Test). This will make sure end users don’t complain, and you get to keep your job.

There is a reason both steps are manual:

First of all, as of now, no AI will be able to understand how and why you developed your features. If a robot could review your code, then admit it, a robot can write your code and a lot of us would be out of business.

Also it is to ensure personal accountability for approvals, so people take it seriously.

If you work in an agile project environment the technical and business review might be detailed as a Definition of Done (DoD, aka “the list of things you need to accomplish to burn the story points”). A sample DoD can look like the following list:

  • Document your feature
  • Get peer approval
  • Ensure business test script is available
  • Deploy to QA
  • Test and approve story by business

So wouldn’t it be nice to tie the technical capability to move a feature to the next environment and release it based on the completion of your DoD/Quality Gates?

Validation rules & history tracking to save the day

Before we jump into any config work, let’s get an overview of what we need and what elements (fields, automations) Copado offers already:

DoD Element

Required

Available

To Configure

Document your feature

Field to indicate document location

Yes, but not in the way we would like it.

Create hyperlink field.

Validate, that the field is not empty.

Get peer approval

Field to indicate approval

Yes, but we don’t jump into pull requests. Maybe later. Start small now.

Create Checkbox.

Validate, that the field is checked.

Ensure business test is available

Indicator for approved test script

Yes.
But I would like to automate the checkbox, and also, I don’t like the current name.

Create Checkbox on User Story to indicate approved scripts.

Update the field on an approved test script.

Validate, that the field is checked.

Deploy to QA

Indicator for current org of a feature

Automated by Copado

Nothing to do.

Test approved by business.

Indicator for approved tests.

Yes, but the automation needs to be configured.

Create Checkbox on User Story to indicate a successful test.

Update the field upon a successful test execution..

Validate, that the field is checked.

To sum up, in order to implement our quality gates we need:

  • 4 fields
  • 4 validation rules
  • 2 processes

And to make sure we can track who changed the checkboxes, we will set Feed Tracking on all of them, so that we see a nice history of DoD on the chatter feed related to the User Story. Also we need to modify the layout to make sure fields are displayed.

Create the required fields

Starting with the fields, we create the following custom fields on the Copado User Story object:

  • PeerReviewPassed__c, Checkbox
  • TestScriptReady__c, Checkbox
  • TestScriptPassed__c, Checkbox
  • DocumentationLocation__c, URL

For those who need a deeper explanation, click here.

Ensure accountability through history tracking

Next, we will enable those fields in Feed Tracking (Setup → Customize → Chatter → Feed Tracking → User Story). Enable the Object Field tracking if required, and select the fields we just created. Add more fields, if you consider them worth tracking. Status is always a good one.

Enforce process adherence with validation rules

Next, we need to tackle the validation rules.

As explained in the first post, a user story is deployed to the next environment, when the “Promote & Deploy” checkbox is checked. Also, it can be selected for a manual promotion if you check the “Promote Change” checkbox. So our validation rules should fire in the following logic:

  • If the story is still in the Dev environment, fire when:

    • “Promote & Deploy” or “Promote Change” is checked
    • Documentation Location is empty
    • Peer Review Passed is unchecked
    • Test Script Ready is unchecked

  • If the story is in the UAT environment, fire when:

    • “Promote & Deploy” or “Promote Change” is checked
    • Test Script Passed is unchecked

Modify the layout to make it easy for users to follow

We added a lot of fields, so let’s make it better to manage for the end user and modify the layout. Copado has already some fields, which we do not use in our cases, such as Documentation Complete, because they are not entirely for the case (also it’s about showing what can be done, right?).

However, there is a field called “Apex Tests Passed”. It’s a checkbox and it is set automatically, if you hit the “Run Apex Tests” button on the story, and the classes in your User Story have sufficient coverage. Also, there is already a section called “Definition of Done”. We will just remove unwanted and add our new fields.

Looks nice, and has a certain logic. Let’s check the validation rule:

Perfect.

We are done here, so the only thing left is to set up the process builder automations and go for an after work drink with colleagues and/or friends.

Reduce redundant clicks with process builder

The key here is to fit into the Copado approach a little to get our automations started. Our favorite release management tool assumes, that a test script might not necessarily be written by a single developer, but also by a larger team, where a test script review process can be part of a test script creation. (Yes, those testers again…).

In order to indicate, that a test script is ready, the status needs to be marked as “Complete”. And that’s all the details we need, in order to create a process builder:

  • Object: Test Script (copado__Test_Script__c)
  • Event: On record creation or update
  • Conditions: Status equals Complete

As an immediate action, we want to update a record related to the record, which triggered the process. The object we want to update is the User Story, and the field we want to set is the Test Script Ready field, which should be checked ( = TRUE).

What we also could do is to set the status of the story accordingly (e.g. “Ready for Testing”), but that is not required for now.

For automating the check of the “Test Run Passed” object, we will create a different, but similar process.

  • Object: Test Run (copado__Test_Run__c)
  • Event: On record creation or update
  • Conditions: Status equals “Passed” or “Passed with Comments”

The immediate action, in this case, would need to update the Test Script Passed field on the related story. So it is more or less the same as for the process created before, just the target field changes to “Test Script Passed” = TRUE.

Done. Well, you should test it, of course 🙂

Try that with Jenkins. Or Bamboo. Or TeamCity.

Gosh, I love this tool.

That’s all nice, but what else could you do?

Although this is a rather simple scenario, it will help already any user to follow the process, although they did not study the process before intensively. Simply by setting up the tool correctly to support what we outlined with boxes and arrows and providing information on how to proceed.

We can now easily check on DoD status of stories with list views or reports to find gaps. If someone asks “Who approved this?” we just need to check the list of chatter posts generated by Salesforce. If we now start to discuss User Stories using the Chatter Feed, your team will be best buddies with any internal project audit initiative.

Going a step further, validation rules can help to cover more complex scenarios, e.g. allowing to validate, but not to deploy to a specific org.

And if your project has issues with code quality, a code analysis tool can be an enabler for your code review. Copado has a build in support for an open source framework to analyze Apex (PMD) but if your team is using CodeScan or Checkmarx for analyzing code, I have been told that CodeScan will be available in the next version (Copado v12) and Checkmarx integration is on the roadmap.

For those who want a more structured technical review process, Copado can be set up to mirror pull requests as records linked to the User Story, so with a checkbox, a process builder and a validation rule you would be able to prevent deploying stories, if a PR has not been passed yet.

I am aware that following a release process sometimes is annoying for developers, but there are good reasons for certain checks and why to perform them, even though the change seems small.

But thanks to tools like Copado following the required steps is a breeze and automating repetitive field updates or notifications, you can ensure frictionless releases.

[Salesforce] Mason Frank Salary Survey 2019 Edition: how to increase your earning potential in Salesforce

 
Given the rate at which Salesforce has grown over the last five years, sometimes it can be difficult for professionals to get a measure of where they fit into the ecosystem and what they are worth. What’s more, it’s important to be aware of what Salesforce’s vast user base is saying about the technology, so you can decide how to move forward in your career based on product adoption and patterns in the market.

The Mason Frank Salary Survey is the largest annual independent study of the Salesforce community. It is an invaluable resource for Salesforce professionals, partners, and customers looking to gather insights into the working culture of the technology ecosystem, and to benchmark salaries, benefits and market trends.

Here is a selection of findings from the 2018/19 survey report, with context on what this means for you as a Salesforce professional and how you can use the information to better your career standing.

An Italian in Salesforce

While commentary on Salesforce usually focuses on the USA and UK, the ecosystem extends all across Europe. Professionals working in Italy will be pleased to learn that their salaries are in line with the industry standard and, in some cases, are higher than one would expect in other major European countries.

For example, a junior-level technical/functional consultant in Italy can expect to earn around €34,000, which is the same as in the Netherlands, but €1,000 more than in Spain. However, it’s substantially lower than in Germany, where a junior technical/functional consultant can expect to earn around €62,000. If you’re willing to travel to find a new permanent contract, Germany would be a good place to look!

Specialist roles are very well paid in Italy. A junior-level Technical Architect can expect to earn around €40,000, which is €6,000 higher than in France. Solution architects are also clearly in high demand, as a junior-level profession of this specialism can earn up to €76,000. For perspective, a junior-level solution architect in the UK earns in the region of £60,000, which converts to around €68,000.

Which Salesforce product is the most in-demand?

One of the more exciting elements of working with Salesforce technology is the way the platform keeps evolving by developing new and innovative solutions for businesses around the world. The downside of this for Salesforce professionals is that if you don’t catch wind of industry trends, you can soon be left behind.

Salesforce is ultimately a sales-centric platform, so it may come as no surprise to learn that the most popular standalone Salesforce product is still Sales Cloud—82% of respondents to the Mason Frank Salary Survey reported proficiency in Sales Cloud, compared to Service Cloud (63%), Community Cloud (44%), and Marketing Cloud (31%).

The popularity of Sales Cloud shows no signs of dwindling, with 52% of respondents indicating that Sales Cloud was the most in-demand product over the last year. Despite being the least prominent of the major Salesforce products, Marketing Cloud was predicted to be the most in-demand product over the next 12 months. This could be attributed to Salesforce’s recent acquisition of Mulesoft, which will make it easier than ever to harness and utilize customer data across multiple Salesforce products.

Where do Salesforce professionals work?

With Salesforce being a cloud-based CRM, the ability to access data online makes it far easier to find remote permanent and contract roles. Despite this, 89% of respondents to Mason Frank’s salary survey were employed on a permanent, full-time basis. It’s an interesting finding given the value and accessibility of the contract market in Salesforce.

Salesforce is the world’s number one CRM for a reason, and there is a substantial number of businesses around the world now utilizing products from the Salesforce business suite. In fact, 50% of all respondents indicated they work for an end user/Salesforce customer, with 41% working for a partner.

What is the experience level of the average Salesforce professional?

Experienced Salesforce professionals are in high demand, with employers always on the hunt for skilled and experienced pros to lead projects and implementations. The majority of professionals working in the ecosystem have between zero and six years of experience; 37% reported 0–3 years’ experience, while another 37% reported 4–6 years of experience. Only 6% of respondents to the Mason Frank study have over 10 years of experience on the Salesforce platform. If you are one of these professionals, you are part of a very exclusive group!

Are you a Trailblazer? If so, what rank are you? Did you know that around 22% of Salesforce professionals hold more than 100 Trailhead badges? This demonstrates the success and growth of Trailhead, given that just 9% of respondents to Mason Frank’s salary survey last year reported holding over 100 badges.

As well as Trailhead, Salesforce professionals have also embraced the technology’s certification structure, with 77% of respondents to the survey now holding at least one certification. As you would expect, the most popular certification is the entry-level Salesforce Certified Administrator credential, while just 6% were a Marketing Cloud Certified Email Specialist.

If you are not yet certified, you may be interested in learning that 39% of respondents reported an increase in salary after gaining certification. This could be a fantastic way to increase your earning potential, particularly as 75% of certified respondents reported that their employer contributed to the cost of certification—it’s an even better investment if you’re not paying for it!

What to take from this information

We can take several things from these findings. Firstly, becoming a Sales Cloud expert is a safe bet—it’s the most popular standalone Salesforce product by far, and given its dominance in the CRM market, it’s never going to go away.

By contrast, Marketing Cloud is predicted to be the most in-demand product over the next 12 months, and given that only 6% of respondents were a Marketing Cloud Certified Email Specialist, this could well be a niche worth exploring if you haven’t yet settled on a specialism.

If you are already deep into your Salesforce career, always be mindful of how much your experience is worth. Download Mason Frank’s 2018/19 Salesforce salary survey in full for a detailed exploration of salaries, sorted by location, role, technology, and level of experience.

[Salesforce / Release Management] Automation for the win!

You hate manual tasks and you are working on a Salesforce.com implementation? Then get a pen, a piece of paper and install & set up Copado.

Why Copado? Because it’s a great solution to manage releases of and with Salesforce.

Why pen and paper? Because it’s a great and versatile tool for drawing your current process and highlighting automation possibilities.

Things are ok. But can we make it better?

A couple of weeks ago, we have installed and set up Copado to manage our release process.

Committing to and deploying based on Git version control turned out to be easier and more secure than working with change sets (finally you can track who screwed up your stuff and restore it).

Next, we took some time to think about the people involved in an implementation, and how projects can work better as a team to release faster and better.

So now, as our team is aligned and everyone has confidence in the process, during the retrospective, the team decided to further improve the process and automate some of the steps.

  • Avoid manual step after deploying a custom setting to change endpoints
  • Ability to commit and deploy dashboards with running users, because it is just annoying
  • Mitigate bad development practices hard coding IDs
  • Send a notification to testers, once a user story is in the test environment

Deploy the same, but different

There are items in software development, which need to be modified based on your environment. Typical cases are integration endpoints, which change depending on if you want to connect to a development, test, or production instance of e.g. SAP. In Salesforce, you can add further items to the list, like IDs, if you want to exept an admin profile users from a validation rule. You can hardcode it as part of the formula (bad, think about kittens and unicorns) or you can put the ID in a custom setting, which is better, but still requires a manual step after deployment, updating the setting record in the target org.

Here is where Copado can help you to automate those steps with the concept of Environment Variables.

If this is too technical and not emotional enough, we will get rid of any manual changes related to hard coded IDs or URLs. Regardless if they are part of a Custom Setting, Validation Rule, Visualforce Page or Class. Believe me.

How does it work?

If you define a specific string, Copado will recognize it and translate it to a variable name, which you define. And upon deployment, it will replace the variable with the string you defined for your target.

Setup Environment Variables

In our case, we will set up an enVar (Environment Variable) for an endpoint, a user and the Admin profile Id.

  1. Get a clear view on your current unique strings. A table works best. Feel free to use pen and paper, if you like.

  2. In Copado, go to your active Deployment Flow, and click on the “Manage Environment Variables” button.
  3. Create a new Variable with the name you prefer. To keep an overview, I prefer to use a naming convention: elementType_usageOrItem
  4. Populate the string per environment or copy&paste from your table to Copado.

Follow the same steps for the other strings, and you will end up with something like this:

Use Environment Variables

So, let’s go ahead and deploy those items. The running dashboard user is part of the xml file, so it’s ok if we just commit it. The same is valid for hard coded IDs in classes or validation rules. However, the custom setting is stored in a record, so it needs to be handled differently.

  1. Create a Copado User Story.
  2. Go to “Commit Changes”, select the dashboard, underlying report, endpoint custom setting (in case it is not deployed yet) and the validation rule with a hardcoded Id.

  3. Provide a commit message, and click on “Commit Changes” to finish the process.
    Take your time to review the commit and see, if items have been added to Git as expected. On the dashboard, you will see that the Running User tag has been replaced with the variable name. The same happened with the Id in the Validation Rule.

  4. Ok, so commit is done, but we still need to account for the custom setting. On the User Story, scroll down to the “Deployment Tasks” related list and create a new task: after deployment, type: “Custom Setting”, select your setting, and click on “Get Custom Setting Values”
  5. Once you have the list, select the setting records you need, and save the step.

Well, this is the moment!

Will it work, will it deploy and replace?

Check the “Promote & Deploy” checkbox on the story to see Copado Magic at work.

Deployment Done.

Log into UAT.

A quick check…

All items were resolved. Perfectly!

Apart from deploying the custom setting, Copado has moved the setting entry, and exchanged the URL in the Target field correctly.

The Id in the Validation rule was replaced:

The Dashboard in UAT has the expected CEO running user:

As Copado applies this mechanism to all files, with a single entry we can account for hard coded IDs or URLs in all Salesforce Metadata, including visualforce pages or classes.

Process Automation

Ok, now the deployment is done, the user story is in UAT, and although we don’t have to update IDs, we still need to notify the tester that the story is now available for review.

Easy, because we are working on the Force.com platform, and Copado provides all the information required.
When a story is deployed to the next environment, the Field is updated by Copado automatically (Dev1 → UAT in this case). Also, there is a Test-Script Owner field on the Story, which is linked to a user record.

In technical terms: We have a DML operation and an email on a lookup parent record, so we have tons of options.

Which salesforce automation tool do you prefer? We can use Workflows, Process Builder, and Apex to fire an email to the user story tester or to a generic email address of the test team.

But email? This is so SAP. What about a chatter message instead?! Process it is.

Create a new Process on Creation or Edit of the story record, to fire for all Stories where:

  • The “Test Script Owner” field is not empty (Test Script Owner → User Id).
  • The “Environment Name” field equals “UAT” (Environment → Environment Name).

Next, create an immediate action of type “Post to Chatter”.

To get the notification right, you only need to consider, that @mentions from process builder require square brackets: @[ mergeFieldOfAUserId ]

If you cannot find the Chatter action on the User Story, enable it for the User Story object in Setup → Feed Tracking.

From now on, when we deploy a user story to UAT, there will be a chatter message on the record and the tester will get notified too (also via email, depending on the settings).

Copado & Force.com: A lot of value for little time invested

Now you might want to know how much time and effort it really takes to set up this type of automations.

To be honest, it took me longer to go through all environments and get the correct values than to set up the environment variables. But in most cases, projects have this information as part of their org-refresh steps documentation.

The main “difficulty” setting up the process was getting the @mention syntax (you are welcome 🙂 ) and improve on some type-os.

It is so incredibly easy to automate even complex scenarios that I set up another action for user stories in UAT to get ahead of my team requirements: Run all unit tests in UAT. But not as part of a deployment, because it’s too easy and this might slow down the deployment. Instead, it should happen after the deployment is finished successfully.

The only thing to do here is to create another condition in our Process (Environment = UAT), and create an action of type “Apex”.

Copado provides a set of helpful methods, which can be triggered in Apex or from the Process Builder, and the one we pick is “Invoke Run All Apex Tests for an Org”. As a parameter, we provide the Org Credential Id of the user story.

Now all apex tests will be run, once a story is successfully in UAT.

Done. It took longer to write about it, than to actually set it up.

One platform. A lot of possibilities

Usually, the tools for committing, deploying, tracking/managing stories and testing are separated. But Copado puts all of it on the highly flexible Force.com platform, so that users can tweak it how they like.

  • Automatic deployments to Stage once testing is done? Create a Process Builder to check “Promote & Deploy” once there is a successful test execution record.
  • A nightly validation deployment of all stories in Stage to Prod, just to check if there would be any issues? Well, you would need Apex to bundle the user stories and fire the deployment. Basically Query & create records.
  • Auto-execute regression testing after a deployment? Record your Selenium Script and add it to be executed after deployment to a certain environment.
  • You can even go crazy, read the information on committed metadata and auto-deploy only if less critical items such as Report Types have been committed. Dev to Prod including a sync back to Dev2 and the only human intervention would be the commit process (include an approval on QA though. We still have to follow the process, and you don’t want testing to be mad at you).

    If this is too technical, and too little emotion, maybe this explains better how it feels now to release features:

[ORGanizer Sponsorship Program] Panaya joins the ORGanizer sponsors family

 

#SalesforceOhana greet our brand new ORGanizer sponsor Panaya!


Panaya - A powerful solution for admins and developers to understand the scope and impact of planned changes and ensure risk free Salesforce deployment


Admins and developers with complex orgs, lots of custom and third-party components, and their related inter-dependencies, struggle to understand the scope and impact of planned changes.

With Panaya Release Dynamix gain a full view of change dependencies and usage statistics so that you can understand the impact of all code developed before going to production.

With automatically generated tests, based on an analysis of the chosen components and a list of related testing entry points, Release Dynamix for Salesforce helps to ensure safe deployment to production.

Panaya will keep company to you in the next months on the ORGanizer main page.!


If you are interested in joining the program, leave a message on the ORGanizer Sponsorship Program form.

May the Force.com be with you all!

Mason Frank 2018 Salesforce Salary Survey is OPEN!

 

Have your say on the Salesforce community!

The annual Mason Frank salary survey is now open and waiting to hear from Salesforce professionals like you.

The survey examines the salaries, benefits, market trends, and developments across the entire ecosystem, combining the anonymous thoughts and input from members of the Salesforce community, as well as info from Mason Frank’s customers.

For anyone working with Salesforce, this is a valuable resource, and your input helps to make the survey as accurate and reflective of the community as possible. Last year just under 4,000 people responded to the survey, further proof that Salesforce professionals care about the community their part of!

It takes about 15 minutes to complete, and there’s a chance to win an iPad, a Nespresso Pixie, or a Google Home device too.

The results of the survey will be released at Dreamforce 25–28 September 2018, but if you can’t make it, the full report will be available to download shortly after the event.


Have a read at last year Italian Salesforce market analysis post for 2017 MasonFrank Salary survey.

5 ways to command a higher salary in the Salesforce ecosystem

 
Are you looking to increase your Salesforce salary? Chris Thompson from Salesforce recruiter Mason Frank International gives his top five tips to maximize your earnings in the Salesforce ecosystem.


Salesforce is the number one CRM platform in the world, powering small and large companies with its expansive suite of business products. Given the popularity of this technology, the demand for qualified Salesforce professionals has never been higher and, as a result, the Salesforce Ohana has never been more valuable.

But how do you go about getting that all-important pay rise?

As a specialist Salesforce recruiter, Mason Frank knows exactly what employers are looking for on a resume, what makes you a stronger candidate at face value, and what you can do to increase your salary in your current job role.

Here are our five tips for commanding a higher salary in the thriving Salesforce ecosystem.

Become an expert in a niche or focused industry

Salesforce is a technology that services a huge range of industries, and branches even further when taking into account the many individual Salesforce products and modules. One way to make yourself an in-demand asset, and a high earner as a result of that, is to refine your skillset to such a degree that you are considered the authority in a specific niche.

Who does a toothpaste manufacturer go to when they need someone to manage their email marketing campaigns? Who does a large energy supplier go to when they need to train their huge workforce to navigate a custom Sales Cloud build? Everybody has an area of focus and expertise, and if you can find yours, you could earn a lot of money out of it.

Get Salesforce certified

Salesforce certifications not only endorse you as a talented Salesforce professional, but also offer the opportunity to enhance your knowledge of a specific area of the Salesforce platform. Some employers have unique build projects, and as such require specific certifications when recruiting. Others won’t even consider a candidate unless they have at least an ADM201 Salesforce Admin Certification.

The only downside of Salesforce certification is that the training and exam fees can be somewhat costly. If you’re fairly new to the Salesforce ecosystem and are looking for a way to gain three fully funded Salesforce certifications, you should check out our Mason Frank Tech Academy. We offer expert training to prepare you for your certification exam, and even give you hands-on experience working for Salesforce Partners—a great route into the Salesforce ecosystem that will automatically increase your potential earnings.

Compare your salary to the industry average

One of the simplest ways to highlight that you deserve to be paid more is to compare your wage to the industry average. Find an independent study on Salesforce salaries and use it in your next performance review to leverage a pay rise. Our Salesforce Salary Survey contains remuneration statistics from major countries across the globe, and even breaks some countries down by region and state, so you can see what you should be earning based on your local economy.

Become a contractor

Given the scope of Salesforce implementation and development projects across the globe, sometimes it makes no sense for a business to take on a permanent staff member to administer its CRM; this is where it pays to be a contractor.

If you are an expert in your field, geographically flexible, and have excellent project management skills, becoming a contractor is a serious option for you. Not only is the complexity of your work taken into consideration with your salary, but also the need for you to pick up and temporarily relocate, and all the rigmarole that comes with it. This equates to huge earnings. Check out our salary survey to compare permanent and contract rates for your job role—some Salesforce daily rates are eye-watering.

Grow your personal brand and become an influencer

Salesforce is a very community-driven ecosystem, and there is a lot of merit in sharing your knowledge to enrich your peers. This will not inherently increase your billable value as a Salesforce professional, but the networking element of this is invaluable, especially if you use your position of influence to work with partners and ISVs to develop, release, and promote new Salesforce products.

Your motivation should always be to enhance the Salesforce community, and you may even be given recognition for your hard work by being awarded Salesforce MVP status. The Salesforce Ohana is set up in such a way that the more you pay into it, the more you will get out of it, which is a great deal for dedicated Salesforce professionals who plan on enjoying a career in the ecosystem.

So to leave you with five simple things you can do today to increase your earning potential:

  • Identify a focused career path and work to become the go-to professional in that niche.
  • Pursue Salesforce certification, utilizing free training and support.
  • Use independent salary research as a benchmark when negotiating.
  • Become a contract worker.
  • Leverage your blog or social media to increase your visibility in the Salesforce community.

[ORGanizer Sponsorship Program] AutoRABIT joins the ORGanizer sponsors family

 

Give your warmest #SalesforceOhana hugs to AutoRABIT, our brand new ORGanizer sponsor!


AutoRABIT is the best application release automation (ARA) tool for Salesforce. It is at the center stage in the Salesforce ecosystem today for its advanced and comprehensive features. It enables continuous integration and delivery by providing fast, simple, and secure end-to-end automation across Salesforce implementations.

In today’s fast-paced world, organizations are under an increasing pressure to run their entire release cycle faster. They must optimize their delivery chain and deploy at the speed of digital and with higher quality. AutoRABIT offers automated metadata deployment, version control integration, advanced data loading, org and sandbox management, test automation, and reporting. It drives business agility and helps enterprises achieve higher release velocity (days instead of weeks/months) & faster time-to-market. AutoRABIT helped 50+ Fortune 1000 companies with effective solutions and improved application release times by as much as 55%.

For further information, contact us at [email protected]. One of our Salesforce experts will get in touch with you soon.

AutoRABIT will keep company to you in the next days on the ORGanizer main page…and hopefully more than this!


If you are interested in joining the program, leave a message on the ORGanizer Sponsorship Program form.

May the Force.com be with you all!

[Salesforce / VCS ] The team factor (or How a business analyst can affect the overall delivery speed)

In the previous post, we outlined a simple process, which did not solely focus on development but instead considered the path a feature takes from definition to production deployment. A, well, release process.

And although for us Salesforce developers it seems tons of unnecessary overhead, there is a reason, why multiple parties are involved: it’s a system of checks and balances to make sure that features are stable and according to end-user expectations.

Imagine you shop online for a TV and you get delivered a simple 23” monitor. It’s kind of similar, but not what you wanted. And although you can see a movie on it, it will not fit the use case you had in mind when ordering a kick-ass UHD supersmart ludicrously large television.

A process introduces the necessary structure for defining, developing, testing and delivering a feature so you can watch the world cup with your friends (no jokes about Italy please…).

We also introduced Copado as our release management platform in the last post, and we did not ditch it. It allows to unify and drive the collaboration between teams, and there are specific items, where I think Copado help teams to do their job.

But I want to take a step back further, because in order to know how a tool can make a process more efficient, we need to understand how each team in a project impacts overall delivery time. So instead of talking about technology, I want to focus on people in this post, describe the roles typically involved in a Salesforce implementation, their tasks and what each team member can do to improve the flow.

Excuse me, but: what exactly are you doing?

Let’s recap the process focusing on the tasks per team member:

Define a feature:

Working in an agile way, a feature is usually defined by client business stakeholders, ideally by the product owner. As there are a lot of features to be defined and also tested, the project setup includes one or more business analysts to support the product owner in story definition, documentation and follow up. Toughened in uncountable meetings and armed with knowledge about the business process they tend to become advocates for the business side and bounce ideas with developers to get a feature done in a way business will like it. We could spend a whole post on that topic, but for now: time for action.

Develop a feature:

Well, do magic. But stay in time and in scope. Oh, and please, make it as scalable and maintainable as possible. You know, the usual.

Peer or Lead Dev review and rework:

Regardless if you just do a face to face explanation or if you use a more structured approach, such as a pull request: having your development reviewed has too many benefits to skip it. It prevents you from introducing a bad design crippling the project in the long run for short term success. Insights are shared within the team so there are no surprises. And you become a better developer through feedback.

If you work with Git (which is surprisingly easy with Copado), a pull request can prevent you from introducing bad items in your feature branch, which at the end will result in easier deployments.

Deploy to QA:

Well, this can be easy or an endless pain. If you work with Git, follow the golden rule, and you should avoid most of the issues:
– Review your commits and never include other people changes as part of your branch. (See why the pull request comes in handy?)
– Less references → less potential deployment errors or conflicts.

Test a feature:

There are elements in this world, which are natural opponents bound in eternal struggle. Water and fire for instance, or cats and dogs. And of course:


(copyright: https://www.monkeyuser.com/2018/the-struggle/)

Yet, without testers, our features would be less robust and might not be according to business requirements. Or even worse, we could break existing functionality. And believe me, you rather prefer a testers feedback, than explaining to your project manager and business sponsor why you broke the internet. On larger implementations, you are more likely to have a QA team focussing on writing and reviewing tests for current developments and automating regression testing.

Finally, the approval of a feature, at least in agile, can only be performed by product owners or delegated business users.

They ordered a TV, so only they are entitled to approve they received one.

Teamwork in software development is a real thing

Great, now we know the main roles involved in a project. But how does that help us to improve our releases? I mean, those business analysts, they don’t do development or any Git stuff; just talking, meetings and powerpoints. How can they possibly impact delivery speed?

A lot.

Analysts: Define and conquer

User stories are an easy way to capture requirements. Right? Well, yes and no.

Yes.
Because the basic format is easy. For instance: as a user, I want to see how much is an account worth, so that I always know on what to focus during sales and service.

No.
Because it misses tons of details. How do you calculate an account’s worth? Where should you see it? In which moment? Do we need information from other systems? If so, do we need it in real time? This simple story could result in fetching the latest orders from the ERP system on account page load.

Here is where the business analyst would spend time with the client, guide them towards a reasonable solution and future iterations and document it as part of the acceptance criteria.

Regardless of your project framework and methodology, good acceptance criteria fulfill at least three criteria:

  • Provide process context.
  • Provide enough information for the developers to know what to do, so they can outline a design and estimate the effort.
  • Be precise enough to be testable. Who needs to log in? Where should you navigate? What action do you need to perform to get a result?

Ultimately, the time invested in documenting decent acceptance criteria will result in multiple benefits for other teams. For instance, less guesswork for developers during estimations and test scripts can be written in parallel with development.

As we use Copado as our release management solution, the User Story created by analysts will be used by developers to scope and deploy the changes. How neat is that? Definition, estimation and deployment all aligned.

Developers: A short cut for you but a long run for the team

After a feature is defined (estimated, prioritized and included in the sprint backlog) it is time to develop it. Done.
But is there anything a developer can do to increase process efficiency?

Just as the business analyst can impact overall speed by investing time in preparation, a developer can impact delivery to production investing time in working according to best practices and reviewing his or her work.

  • Documentation, for example, is something most devs dislike, however it is crucial for others to understand the overall design and making informed decisions when moving the feature towards higher environments.
  • Writing org-independent apex tests, which don’t rely on existing data. Just remember: every time you write @isTest(SeeAllData=true) a kitten dies with puppies crying and unicorns get sad.
  • Do not hardcode references to a specific org. Do that and the unicorn will fade away.
  • Check your feature branch, if you work with Version Control (Git). Always make sure that, whatever is committed in your feature branch includes your feature only. A peer or pull request review process can help to catch those wrongly committed items (e.g. reference to a field you don’t expect in a layout or a report type).
  • Make reviewing easy. How? Well, what about pasting the URL for feature definition and documentation in the pull request description? Takes less than a minute, but saves minutes in searching for the reviewer.
  • Perform a validation deployment towards the target org including running the test classes.
  • Write down pre or post deployment tasks in an understandable way, because it might be that less tech-savvy team members need to perform them.

So that’s it? Well, not entirely.

With the right solutions in place, such as Copado, you can even go further, and there is a good reason to do so: there’s more than one deployment.

In our setup, there are two deployments required to release a feature. One to QA and another to Prod.

But what if your pipeline has further orgs? Staging, for example, a hotfix org and multiple dev sandboxes? In such a scenario, each manual step needs to be executed multiple times for different orgs.

Luckily Copado has some fancy logic under the hood, which can increase the level of automation considerably, so that you don’t even need to worry about hard coded references (yes, indeed).

In the next post we will take a closer look on how this can be achieved, but just as a teaser, the magic words are: Deployment Tasks and Environment Variables. And of course: “Please”.

Test team: Heavy lifting – easy testing

In an ideal agile world business testers would just check the functionality against the acceptance criteria and say yes or no, but the reality paints a different picture. Client stakeholders are caught between user story definition workshops, maybe their ongoing non-project work, internal stakeholder management and testing. Therefore a dedicated QA team can be of great value to drive testing effort, where better preparation results immediately in a shorter test time.

As soon as a feature is in a QA environment the clock starts ticking, so the core objective of the QA team is to make sure, that everything is ready for client business stakeholders to test and approve the functionality (or reject it (-_-) ). Here are a few things the QA team can do to prevent a story being stuck in testing:

  • Ensure you have a test script indicating the steps to follow to achieve a certain result. If acceptance criteria are well documented they will come in handy to work on them in parallel to story development.
  • Get the test script steps approved from a peer, who ideally dry-runs it on the dev org if the feature is available.
  • Make sure testers have access to the org with the appropriate permissions to execute the test. Just in case, because who would miss something that obvious, right?
  • Dry run tests in QA org, to avoid any surprise. Not required, but highly recommended.
  • Identify a test owner who will perform the test, with the help of business analysts and/or product owners.
  • Chase and support business for and during testing. Make sure they are notified and co-ride tests to support their efforts.
  • Chase and support developers if issues are found and a fix is required.

If you think: “That sounds like a lot of documentation, tracking, monitoring, and coordination.”, you are completely right and tooling can help here which in our case it is an easy thing. We defined the user story in Copado with all the required agile information, then developers used it to commit and deployed their changes to QA. The test team can use the same User Story record to define their scripts and track execution. Nice.

Release Managers: Connect the dots to align

Analysts document, developers work according to best practices, testers prepare. So, what can release managers do to move features faster to prod? Apart from the obvious tasks this role implies (e.g. helping teams to fix errors and resolve conflicts) release managers are owners of the overall release process, the technology enabling it and as a result they need to run continuous improvement efforts. Sounds like lean management? Absolutely. Reducing errors, increasing automation and avoid waste (including time) are key lean principles – and still valid, although we produce software instead of cars (or TVs).

Ok, let’s say I’m a release manager. What do I need to do?

  • Increase tooling knowledge. Regardless of which tool you use, you can only apply what you know, and being aware of what a tool can do is your foundation.
  • Monitor and analyze the process. What are the steps done by the team? How long they usually take? Is there anything which you might have missed?
  • Analyze challenges. Some deployments are easy, while others may take ages. List them down and investigate the root cause.

Once you have a good overview you can start applying your knowledge to tackle the issues:

  • Identify and implement automation. Even smaller improvements add up. For instance, we could fire a message to the assigned tester as soon as a story is in QA and the script is approved. With Copado this can be done easily with a process builder.
  • Document solutions. Usually deploying Salesforce metadata is easy. Select, deploy, hope, done. Yet some metadata types, such as profiles, standard picklist values or processes have their own tweaks to them. A good documentation of best practices and how to handle specific situations will enable teams to avoid pitfalls.
  • Listen to the team. Yes, people complain – often with a valid reason. So although nobody likes to get complaints, resolving them will lead to improvements.

Because in Copado your overall flow is aligned to User Stories and you have the power of the force.com platform on your fingertips you can tinker around with your Copado installation to provide you the information required. With process builder, you can set up time stamps on the User Story object to analyze the time spent per step and identify bottlenecks. You can even make dashboards and share them with your team.

And if you don’t have a dedicated place where you store process documentation, just create a new object to document solutions, and another one to hand in suggestions (which you later can take as input for User Stories).

Technology does not implement technology. People implement technology.

With all the innovation, features and what not being released each week, we sometimes forget that at the end of the day you work with people. You might like one more than another, however everyone who participates in an implementation is bound to a common goal. There is real value in working together, communicating, helping each other at the cost of being nice. Even to testers.

And once you got your team mojo going, the next logical question is: How to make it faster?

Well, this is the moment when tooling is back on the main stage. Copado has some nice features on how to automate steps in your process and in the next post we will take a detailed look at how to set it up so you spend less time with clicking around and more time with the team.

And watching the FIFA world cup on a kick ass UHD super smart ludicrously large television.

10k You! ORGanizer for Salesforce reached 10,000 active users!

 

In less than 2 years the ORGanizer for Salesforce Chrome & Firefox Extension reached more than 10,000 active users, and there is no way to stop it!

It’s an incredible goal and I’m so proud to help Salesforce users/devs/admins life day by day!

We’ve made a new T-shirt design (thanks to my dear friend Davide D’Annibale) on the ORGanizer Swag store to celebrate this event!

Support the #BestSalesforceExtensionEver with:

We want numbers!

Main stats are being collected since August 2017:

  • 2M+ times popups has been opened
  • 2M+ total events triggered
  • 1.3M+ logins done with the ORGanizer
  • 70k+ credentials stored

Since middle of May 2018 (when the ORGanizer Sponsorship Program started):

  • 55k times the ORGanizer button has been pressed
  • 33k Quicklinks opened
  • 2k sponsor banners has been clicked

This is a worldwide success!

Sessions all over the Earth

U.S.A. counts the most sessions!

And English is the most used language!

I cannot be happier and more proud for this awesome goal and the support from the community has been priceless!

I wanna “10k You” all guys, thanks for bringing the ORGanizer for Salesforce into your lives!

I wanna thank again Davide D’Annibale for his precious help on the graphics part and for realizing this amazing “10k You” image!

Let’s meet again at 100k!

Page 6 of 20

Powered by WordPress & Theme by Anders Norén