Nerd @ Work

When Salesforce is life!

Page 3 of 18

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 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:


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.

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.

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 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!

[ORGanizer Sponsorship Program] Merlin Guides joins our trailblazing sponsors


Today for the next month Merlin Guides joins ORGanizer’s trailblazing sponsors!

Merlin Guides stops your team from making mistakes in Salesforce. By guiding your team, step by step, inside of Salesforce with your interactive guides, your team will know your exact process and exactly the information they need to fill out. Every guide is created in minutes (by just doing the process once yourself) and they are completely custom to your team – your process available whenever the team needs it.

We’re the only solution available in the AppExchange that supports guides that work inside and outside (Bazaar Voice, Asana, Jira…etc) of Salesforce, so we’re great for the complex processes your customer support & sales teams have to go through.

Merlin decreases mistakes, increases adoption and improves your data – by scaling the best training in your company in the best possible way.

Find out more!

Merlin Guides will keep company to you in the coming month on the ORGanizer popup page…and hopefully more than this!

Click the link and find out their incredible service!

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

May the be with you all!

[Salesforce / IoT] Let’s play the game with Salesforce IoT (part 3): Heroku IoT platform


In the previous post we have setup everything needed on the Salesforce side to configure the IoT Explorer.

Before jumping on the Arduino Nutellator 3000 project, we have to create a proxy that will transform data received from the devices in order to push them to our beloved CRM.

For those, like me, who are the typical TL;DR developers, head over the GitHub repository and have a look at this simple NodeJS project.

What do we need?

  • A Salesforce Connected App
  • An Heroku dyno to host the proxy (our own IoT Platform)
  • An Heroku Postgres Database (free tire) to handle basic authentication

What will this app do?

The main job of this app is to create Platform Events filled with the data that comes from the Nutellators and send this events to the IoT Explorer to finally trigger the orchestrations.

N.B. If the last sentence is totally obscure to you, please go back to the first post of this series to learn more about Platform Events and how they are related to Salesforce IoT.

Configure a connected app on the CRM

To send a Platform Event using the REST APIs, you’ll need a Connected App.

To create a new one go to Setup > Apps > Connected Apps and create a new app:

We won’t be needing the callback URL since (so put a protocol://fake formatted url) we’ll be using Username-Password OAuth Flow (more details here).

From this app you need the following info to properly configure the Heroku app:

Next thing you need your user’s username/password/token to complete the Oauth process.

Setup Heroku

Create a new Heroku app (let’s say
Fork the salesforce-iot-nutellator-proxy repository on GitHub.

Click on the Deploy tab and link the forked Github repository:

Do not deploy the code right now.

Add the Heroku Postgres add-on and set everything up

Jump to the Resources tab and look for Heroku Postgres addon (choose the free tier):

Let’s put some settings

Before deploying the code from GitHub we have to setup few settings on the Settings tab:

You should have seen the DATABASE_URL already there: this is the url to access the Postgres database.


Go back to the Deploy page and hit the Deploy branch button:

Last action to make is executing the DB initialization code that creates a iot_user table with a single user called “user” with password” pass: this user (and any other you decide to add) will be used to authorize every request from the device using basic authentication.

To execute the script simply use the Heroku console:

Test it out!

Open the app on your browser using
If everything is ok you should see this message:

Salesforce IoT Proxy 
© Enrico Murru - 2018

Anatomy of the proxy

The Express JS server exposes 2 different routes:

  • GET /: doesn’t actually do anything
  • POST /api/level: this is the route used by the devices to send their data

A typical call would be so formatted:

POST /api/level

Authorization: BASIC BASE64(user:pass)
Content-Type: application/json

    "level": 30,
    "device_id": "T1-C0DE-IRI"

Where device_id is the Devide Id that we’ve seen in the Nutellator Salesforce object and level is the nutell-level of the device in %.

The result of such a call is an update triggered by the orchestration on the targeted device:

In the next and last post we’ll be closing the post series by having fun with Arduino and a Nutellator 3000 project.

[ORGanizer Sponsorship Program] The Welkin Suite in the heart of ORGanizer


Standing ovation for The Welkin Suite, new ORGanizer sponsor for the next month!

We are proud to say that we are the only one-stop tool for Salesforce that effectively removes the pain and greatly speeds up work for Configuration, Administration, and Development.
Our informative design and Intuitive usage allows easy access to sObjects, Field usage reports, FLS editing, inspectors for Fields and layouts, abilities to clone Fields, easy deployments and Org comparison, SOQl, and more. Plus code development for Apex, Lightning, Visualforce, and tools for managing Debugging, Governor Limits, Code Coverage, test running and the list goes on.

The only powerful tool for both Salesforce development and administration– with tools for Apex/Lightning/Visualforce/Declarative Development, and for managing Debugging, SOQL Queries, FLS, sObjects, Governor Limits, Code Coverage and much more with its 100+ features

The Welkin Suite will keep company to you in the coming month on the ORGanizer menu button…and hopefully more than this!

Click the link and install their amazing IDE!

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

May the be with you all!

[ORGanizer Sponsorship Program] sfApex is our newest sponsor!


Just 2 days before the first ORGanizer Sponsorship Program announcement, we are here to give a warm hug to sfApex into our Ohana!

sfApex is a leader in Salesforce data copy.
Quickly and easily populate your sandboxes with data for better testing and faster development.
Their customers experience a 50-70% reduction in time spent populating sandboxes.
You can copy all your data or select specific records to meet your testing criteria.
Eliminate the pain of writing scripts or trying to match thousands of record IDs in Excel.
Spend more time coding and less time creating test data.

sfApex will keep company to you in the coming month on the upper side of the main ORGanizer page…and hopefully more than this!

Click the link and install their astounding sandbox populating app (and ofcourse leave your 5 star review)!

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

May the be with you all!

[Salesforce / VCS] Develop VS Deliver Features in Salesforce

A devs life could be so easy…

Developing a feature in Salesforce is easy, right?

  • Log into your org
  • Use (mostly) some point &bmp; click methods to enhance logic, user interface or the data model
  • Done

Sounds like it is developed.

But it is not delivered.

Although the feature is technically done, it is not available for end users in the production environment. Also, nobody tested if it fits the business requirements or if it breaks existing functionality.
In addition, maybe someone should take a look at your feature, if it is aligned with the overall solution design.
Oh, and in order to minimize business impact, deployments to production may be restricted to specific time windows per week.

Sounds like we as a team should follow a process to release features in a controlled way.

This is how we roll

There are a variety of processes for release management out there as each team is individual, but usually they structure a series of quality gates in a flow.
Taking the example from above, the high-level process would probably look like this:

So far so good, but now we have a challenge.

Production deployments can only be done at certain moments so what happens, if one feature is tested and ready to go and another one is still being reworked, and both share components such as an Account Layout?
Oh, and we want to have a backup of our metadata (not only classes) to be able to roll back, in case we have an issue after deployment?

It would be great, if we could work in a way that tracks changes over time and allows to release specific versions of our metadata.

Git for the save.

As described above, developing on the platform can be very straight forward. But apart from Flows and Process Builder, old versions are lost, once you save your changes, e.g. Classes, Formulas, Validation Rules or Layouts.
To avoid that, you can store local copies of your metadata by retrieving it (e.g. through Workbench or ANT Migration Tool). You can also deploy the retrieved items. So we could use that to account for our prod deployment, but that sounds like a lot of effort to manage those local files and versions.

Here is where a Version Control Solution (VCS) comes in handy. And by the frequency VCS is being mentioned, it has become an important pillar for working with Salesforce. There are several solutions out there (SVN, Mercurial), but as of now Git can be considered industry standard.

So instead of storing retrieved items on our hard drive using different names and folders for tracking versions, we can simply store them in our Git repository, which will track changes. This will allow us to go back to an earlier moment for rolling back changes or deploy a specific version from the past.

That escalated quickly. Can it be easy again?

Let’s take a step back.

What started out as an easy way to build valuable business features, suddenly sounds somewhat complex. Being able to roll back, having quality gates in place, all those are valid points, but now as a developer apart from creating functionality and work peer and QA feedback, you also need to do something with ANT or Workbench then storing it in Git and then deploy it?
Is there an easy way to do this?

Yes, Copado.

To get started, you need to download it from the AppExchange or the website. Also, as the goal is to work with version control, get a free Git repo from GitHub or Atlassian/Bitbucket.
Next you need to connect Copado to your Salesforce environments (Dev, QA and Prod in this case) and set it up with the Git repository. There is a quick-start guide you can follow with links to additional documentation. While you set up Copado, you notice that it is natively build on the platform. So your knowledge about Salesforce is all you need to modify it (This will be important later, so keep it in mind).

Once the setup is done, the process described out above using Git version control as source of truth would be the following with Copado:

Define feature in Copado

Assuming most Salesforce implementations are done in some form of Agile, it can be done in Copado directly, including all required information, such as Sprints, Epics, Acceptance Criteria or Story Points (click here for more details).

Scrum Masters and Analysts can use the Work Manager and Kanban Board to manage stories, roadmaps and sprints.

Develop feature in your environment

Let’s get to the part we like: get creative on how to solve the business issue in Salesforce. This one is easy indeed.

Perform a peer review in your environment

This is done between developers, however, we would like to document the results with a flag to mark the story as “Review Passed”.

Here is when the catchphrase “native” turns into a benefit.
Just create a Checkbox on the Copado User Story object called “Peer Review Passed”, make it available for the required User Profiles and put it on the User story layout. Done*.

*: Wait, you work in Production directly? You can use Copado to deploy this modification.

Deploy to QA

So far so good, let’s go ahead and deploy. Scared?

Just click on “Commit Changes” on the Copado User Story, select your items (use column search and sorting to make your life easy), provide a message and finish your commit.

Back on the User Story page, check “Promote & Deploy”* and the following will be done by Copado**:

  • Create a feature branch
  • Retrieve the items you selected
  • Commit the items you selected on the feature branch
  • Create an intermediate Promotion Branch merge your feature branch on it (more info on the branching strategy can be found here)
  • Perform the deployment using Git as source
  • You can review your selections on the story, and click on the “View in Git” links to quickly navigate to your repository.

    ** bonus points if you click on “Validate” to make sure you can deploy

    Test user story

    Once the story is deployed to the next environment, it will be visible on the User Story page and we can change the status to “Ready for testing” and notify the Test Team through chatter.

    If you are thinking “Wait, this just a record update in Salesforce and it could be automated easily”, you are completely right! Wait for the upcoming blog posts.

    As soon as the test team approves the story, they can set the status to “Complete”.

    Deploy to Production

    Testing is done, and we can move to Prod. But wasn’t there something about other stories modifying the same component and them not being ready?
    Well, this is the beauty of version control. Copado will pick the feature branch contents for deployment and those did not change. Your story is independent and you can work in a true Agile way.

    Check “Promote & Deploy” again.


    That’s it. That’s all?

    Well, not exactly. The tool offers tons of functionality which can make your life easy, such as the way profiles are trimmed and deployed with Git, an engine to remove (or replace) unwanted tags from xml files, modules for recording and automating testing, and the easiest way to handle Salesforce DX you have ever seen. You can even launch internal Copado logic through Process Builder!

    Check out on their demos or browse a little the documentation to get an overview of what is possible.

    We, however, will leave technical feature descriptions aside and focus at improving our process, as there are elements which will need to be tackled to get your team closer to smooth releases.

    • You’ll never work alone, so how to improve releases by working as a team?
    • Deploying with a simple click is maybe too easy. Can we implement quality gates?
    • Those are too many clicks. Can we automate this?

    Look out for the next post, where we will take a closer look at the involved team members and how Business Analysts can play a key role reducing the time required to release a feature.

Page 3 of 18

Powered by WordPress & Theme by Anders Norén