Integrate all your teams with Salesforce Customer 360 Platform

What is the Customer 360 Platform? 

Salesforce Customer 360 is the core Salesforce Platform that connects your marketing, sales, commerce, service, and IT teams with a single view of your customer data, helping you grow relationships with your customers and your employees. It includes a full range of Salesforce products that help your company keep everything connected in one system.


Discover what you can do with the Customer 360 Platform

Salesforce Customer 360 Platform is built to work with countless applications to provide a seamless customer experience that allows you to run your organization smoothly. 

One of the ways you can integrate the Customer 360 Platform with other programs is by using Salesforce Appexchange, a marketplace for apps that can be installed easily into your Salesforce org. Integration can also be done with MuleSoft Anypoint Platform, you can connect any system, application, data, and device to unleash the full power of Customer 360.

Customer 360 has a solution for every phase of your customer’s journey. The more teams you unite, the more you know, and the better you grow.

So, what are the teams you can unite under this scalable CRM platform? Sales Cloud, Service Cloud, Marketing Cloud, Experience Cloud, Slack, and Commerce Cloud just to name a few. 

Customer 360 gives everyone in your company the ability to access crucial data and make smarter, faster decisions.

Discover what you can do with the Customer 360 Platform

We have helped our customers take full advantage of Customer 360 Platform, integrating it with over 30 different technologies. Here are some of the success stories:


External API developer community

Our customer, a large installer of interior finishes for US homebuilders, needed help to grow their external API developer community to promote integrations with builders, suppliers, and vendor partners.

In order to create a new community to support the growth of API for buyers and prepare the way for future APIs, we used MuleSoft Anypoint API Community Manager. Our team worked closely with the customer to create a developer portal that showcases the API with technical and business documentation, and a mocking service to allow developers to try the API on the site. 

Through the Experience Cloud, we were able to customize the community theme to ensure it remains consistent with the overall brand. Using Salesforce CMS cards throughout, we could simplify management of the site’s content and provide a space to showcase APIs in development (i.e. “Coming soon”).  


  • Launched the developer portal and gave access to builders which reduced their onboarding time by 80%


Streamlines Data Management with Salesforce

Our customer, a Professional services company specializing in Salesforce digital transformations, identified an opportunity to create an abstraction layer on Salesforce to simplify and streamline data entry and management for their clients.

Our client partnered with us to build a new application using Visualforce, React, ts-force, and TypeScript to give their clients a better interface to manage events, opportunities, leads, and comments. This new Salesforce application provides a simplified user interface, unifying management for all 4 object types on one page (translated in both English and Japanese). 


  • The key partners and customers will start using the product as soon as the MVP of the product launches. 
  • Companies who use Salesforce to create meeting minutes, action items, input their sales activities and customer details, saved more than 50% of their time.

If you are interested in reading more about our success stories, we recommend you check out Oktana’s Success Stories 

Oktana achieved ‘Expert’ status for the Customer 360 Platform specialization


In 2022 Oktana achieved ‘Expert’ status for the Customer 360 Platform specialization in the Salesforce Partner Navigator program, the highest level for the category. 

As a software development company that helps customers innovate, 100% of our Salesforce projects use at least one of the Customer 360 specializations. Most of these projects require implementation of other Salesforce clouds that we have vast expertise, such as Experience Cloud, Service Cloud, and MuleSoft. 

The Customer 360 Salesforce Specialization requires demonstrated and validated expertise in eight Salesforce Customer 360 areas. Through our customer projects, established demonstrated knowledge and expertise in AppBuilder, Heroku, Integration Services, JavaScript Designer, Mobile, Platform, Process Automation and Security & Privacy.

Did you know we are also Salesforce Summit Partners? Check out how we achieved Summit (previously known as Platinum)

Salesforce TDD (Test-Driven Development)

Hi, I’m Diego and I have several years (I prefer not to say how many, but let’s say “enough”) working in Salesforce. I am also an Agile enthusiast and lover of applying related techniques throughout my work.

I’ve found test-driven development (TDD) can be a great technique for building robust software, but when we work in Salesforce, I find some constraints or restrictions can make it frustrating. In this post, I’m going to show when and how I use TDD while coding in Salesforce.

Disclaimer: The following is written on the basis of what has worked for me in the past. This is not intended to be a formal or exhaustive description. Use it as you see fit, I do not take any responsibility if you screw it up! 🙂

Salesforce TDD (Test-Driven Development)

Let’s start at the beginning:

What is TDD?

TDD is an Agile development technique that requires you to write a failing unit test before writing any “production code.”

How are you supposed to do TDD?

First I’ll describe how TDD is done in general (this is the way to go in languages like Java).

  1. Write a unit test and make it fail (a compilation error is considered a failing test). Write no more lines of code than needed.
  2. Write the least possible production code lines to make the test pass (fixing a compilation error is considered a pass test).
  3. Refactor the code.
  4. Repeat until you are done.

Let’s check out an example in Java so you see how it works. In this example, we wanna create an advanced calculator of integers.


We work in split view when doing TDD

Round 1

Let’s write a failing unit test:

Oops, MyCalculator is not defined yet, compilation issue…therefore, it is a failing test.

Let’s make the test pass:

Compilation problem fixed! The test is passing again. Woohoo!

No tons of code to refactor. 

Round 2

Let’s continue with that test to make it fail again.

Mmm…getOpposite is not defined, ergo compilation issue, ergo failing test.

Let’s fix that. Let’s write the minimum code to fix the test:

getOpposite is defined and returns 0 to any parameter (in particular, 0). Test is passing again!!!

Let’s refactor.

We still don’t have much code to refactor, but there are some name changes we could use to make code easier to read ( yup, yup, yup…unit test code is code, too).

Much better now! 😀

Round 3

Let’s add a new minimum test to fail.

Right now, getOpposite returns 0 to any parameter… it’s a fail!

Let’s write the minimum code required to make the test pass.

Yay! It’s green again! Let’s continue.

Round 4

Let’s add a new failing test.

Last test fail (we are return 0 to any value different than 1), so now we need to write the minimum code to fix this test:

Test is passing again… but this solution is not good, let’s refactor.

Tests are still passing and we solve all the cases! We are done! Well, not actually, we still need to document, test more, write more tests and write even more tests…but we’re on the right path.

I expect this silly example gives you a feel for what TDD is and how it is done.

Now, let’s continue with the discussion, focused on Salesforce.

TDD Advantages

  • Code coverage: We get great code coverage without even thinking about it.
  • Testability: The code is designed to be testable by default (we are actually testing every time we change something).
  • Easier to refactor: We should not change or refactor code without having a set of tests we can lean on. As we are constantly writing tests that we know are able to catch bugs (we make it fail at the beginning), we know that we have a set we can rely on.
  • “Better” code: We are constantly refactoring the code, striving for the best possible code.
  • Predictability: After we finish a “round,” we are completely sure the code is working as we designed it to work and we know we didn’t break anything. We can say we have “working software.”
  • Prevents useless work in Salesforce: In Salesforce, aside from Apex, we have plenty of options to make changes like triggers, workflow rules, process builder, etc. Imagine that after we write a test that changes a value on a contact record, it passes. We could discover that there is another moving part that is taking care of that change (or we wrote the test badly).
  • Documentation: Tests are a great tool to communicate with other developers (or the future you) how, for example, a class API should be called and the expected results of each case.

TDD Disadvantages

  • Overtrust: It happens to me that, as we are testing continuously and we are getting test green, I sometimes have a feeling that the code is working perfectly…but it doesn’t mean it is. We may miss, or simply get lazy, and leave a case out of the unit test.
  • Slow in Salesforce: TDD is designed based on the theory that compiling or writing a test is really fast (a jUnit unit test has to run in less than 1ms). In Salesforce, we need several seconds to compile (the code is compiled on the server) and several more seconds to run the test. In my opinion, this is usually 10+ seconds. As we are compiling and running tests constantly, we add several minutes of “waiting for Salesforce.” However, this can be mitigated if you think you will need to write/compile/execute tests later anyway – you might as well do it upfront.



Me when I realize the QA found a case I had not considered when I was doing TDD

I will (probably) use TDD when...

In general, I’ve found that TDD is a great tool in several circumstances and I tend to do it almost always in the below cases.

  • Back-end bug fixes: Doing TDD in this context has two big advantages. First, you make sure you are able to reproduce the bug consistently. Second, and even more important, as you are writing a test specific to the bug, you know you will never introduce that bug again.
  • Back-end work with clear requirements and a clear implementation strategy: In this context, writing tests is going to be easy and implementing the production code will be easy, too, as you know where you are heading when you create the test cases.
  • Back-end work with clear requirements and minor implementation unknowns: In this context, the test is easy to write and the production code may be getting clearer as you move into cases.
  • Back-end work with some requirements discovery: Imagine in our calculator example you write a test to divide by zero and you realize you’ve never discussed that case with the BA. TDD helps you discover opportunities to clarify requirements.

I might do TDD, but it’s unlikely...

  • As part of requirements discovery: You could write unit tests as part of requirements discovery, and discuss it with your stakeholders, BA, or other technical people, but you probably have better techniques to support this process.
  • Front-end work: I’m gonna discuss this briefly later, when we talk about Lightning web components.

I will never do TDD when

  • I’m doing a prototype: By definition, a prototype or PoC should be discarded after we show it, so I code it as fast as I can, focused on demonstrating the core functionality.
  • I’m experimenting: If I’m trying a new idea, I don’t focus on code quality (again, this is a prototype).
  • I’m evaluating implementation options: There are some cases where you want to compare two implementation options, so focus on having a good-enough-to-decide prototype and throw it away after you decide…then do the stuff well.
  • I don’t care about code quality: I know code quality is not usually negotiable, but in very limited and extreme situations, it may not be the top priority. For example, when everything is screwed up on prod and you need to fix the problem ASAP because the company is losing millions of dollars per minute. In this very extreme circumstance, fix the problem as fast as you can, make your company earn money again, go to sleep (or maybe get a drink) and tomorrow at 10 am (yup, after a stressful night, start working a little later the next day) make the code beautiful with TDD. Make a test that reproduces the bug and then fix and refactor the code properly.



Me again, but on one of THOSE nights.

  • When creating test code is extremely difficult (but not possible): In Salesforce there are a few elements that are very hard to test, like working with CMT. In this scenario, I’d probably split the problem into two parts – one that is TDD-doable using mocking data (@TestVisible is your best friend here) and a second, smaller part that I’d consider how to test later (if I even consider it).

How I do TDD in Salesforce

I really don’t do TDD as I defined at the beginning of this article when I’m working in Salesforce. Why? Mainly because of the slower compile/test flow, but also because in Apex we generally start writing integration tests instead of unit tests. Instead of “regular” TDD, I tweaked the formula a bit to work better under Salesforce circumstances.

  1. Write an entire deployable test that checks the flow or use case. Yup, I said deployable, so if I called a method I haven’t created yet, I will create it, empty, so I can deploy.
  2. Run it and get a failure.
  3. Write the minimum code that makes that test pass.
  4. Refactor.
  5. Continue with the next flow or use case.
  6. When I’m done with all the flows and use cases, I refactor the code again (splitting methods, checking code cleanliness, documentation). I run the unit test continuously, every few changes to check if everything continues to work as expected.

To make everything clear, let’s view an <could-be-real-world> example.

As a user, I want the values stored in any object copied into a number of specified contact fields. The specified “mappings” will be stored in a CustomMetadataType called Contact_Mappings__cmt. The Contact_Mappings_cmt has two fields:

  • Original_Fields__c Text
  • Mapped_Fields__c Text

Round 1

As I said before, I should start writing an Apex test that tests a business case. The first thing I’m thinking of developing is “The contact should not change if there is no mapping defined.” I have to write a deployable test that is going to fail with the minimum amount of code to make it fail:

We work in split view

As expected, the code deploys but the test fails. So, we need to fix it! We can simply return the same object.

Now It passes, but we don’t have a lot of code to refactor (we could extract some constants in the test).

This is a much better test.

Test still passes!

Round 2

Okay, let’s add another case. What if we check that the User.LastName is copied into the contact when I define the Mapping Lastname => Lastname? Great idea, let’s do it!

I start to write the unit test but…. I realize I can’t do an Insert in a CMT. Or, I give seeAllData permission to the test and define it in the project metadata. Or, I have to somehow deploy it. 

Remember that I said that I don’t do TDD when writing the test is extremely hard? Well, it looks like I’m in one of those situations. At this moment, I can quit writing this blog post and go cry…or I can redefine what I am developing with TDD, leaving all the complexities outside of scope. I imagine you would be very annoyed after reading this far to see me just quit, so let’s go with the second option.

I can’t use the CMT right now, so let’s do something different. What if we use a Map<String, String> where the key is the field in the original object and the value is the list of fields names in the Contact Object. It might work, later on we just need to read the CMT and create a Map with that information, but spoiler alert…that won’t be covered in this article.

But okay, great, let’s create a map and write the deployable failing test.

And as it was expected… it fails.

Let’s write the “minimum” code that makes that test pass

Our new test passes, but the other one failed! Let’s fix that.

Let’s do some refactoring, either in test or production code.

I think the put/get part is messy to read (and has its own meaning), so let’s split it into its own method.

Also, as we want that theMap could be injected into test case scenarios, the @TestVisible annotation is useful here.

Round 3

Now we should add a new test that executes a new flow and see it fail. I think you got the idea, so I won’t do it now, but just to specify the cases, I can think:

  • Mapping a field to multiple fields (separated by colon)
  • Does nothing if origin field is wrong
  • Does nothing if destination field is wrong
  • Does nothing if types are not compatible
    …and so on

Can we do TDD in Lightning web components (or front-end)

The short answer is yes, we can.

Long answer: As the Jest test can’t see the objects, but they see only the “generated DOM”, it may be harder to do TDD in an efficient way for front-end solutions. Usually, it is better to test visual code by watching the result and THEN write the tests we need to ensure code won’t break in the future.


TDD is a best practice that’s good to master so that you can decide the best moment to apply it (I don’t believe there is One Ring to rule them all, One Ring to find them, One Ring to bring them all, and in the darkness bind them, thank you J.R.R. Tolkien). Applied correctly it will make you produce better, more robust code…and fewer bugs, which means…

Homer is happy

Why you should attend Dreamforce 2021

Dreamforce starts next week, in just 5 days. If you’re new to Salesforce, you may not know about Dreamforce, the annual event that brings together the global Salesforce community for learning, fun, community building, and philanthropy. It’s an experience where Trailblazers from all over the world gather to share their stories, their successes, and learn from each other.

Why you should attend dreamforce

Why Attend Dreamforce

Salesforce is taking a hybrid approach this year, both on-site and online. Dreamforce 2021 takes place September 21-23, 2021, and will host select attendees in San Francisco, while the rest of the world will join virtually. 

Dreamforce will broadcast globally, for free on Salesforce+. There will be four live broadcast channels and 100+ hours of on-demand content. Salesforce is known across the industry for its excellent events. We highly recommend attending if you are working with Salesforce or would like to start learning more about it. There are four key reasons why you want to be a part of Dreamforce 2021. 

  • Learn. Transform your career with breakout sessions, training, and certification opportunities. Participate in cutting-edge demos. Meet new partners with solutions to help your organization grow.
  • Get inspired. The world’s most innovative minds come to Dreamforce to inspire, excite, and motivate attendees every year.
  • Give back. Attendees help build diversity, inclusion, equality, and sustainability with action and volunteerism. Past organizations Salesforce has supported include Girl Scouts of America, RED, and many more.
  • Have fun. When Trailblazers get together, it’s a party. And Dreamforce is the biggest one of all. Dreamforce is a celebration of the community.


Recommendations to attend Dreamforce 

Are you ready for three full days of non-stop events? There are many sessions and topics, that’s why we have some recommendations for you:

Plan your time: One of the biggest challenges with a virtual Dreamforce will be that everyone is spread across different time zones. Dreamforce has everything you need, from session descriptions to calendar links. Don’t forget to add the sessions to your calendar and keep track of what’s coming. Take a look at the schedule and the episodes, so you can choose the sessions that make the most sense for your interests and responsibilities. During the three-day marathon, we recommend blocking off time to catch up on tasks and stay productive. 

To make your life easier, here are some sessions we recommend. Remember that if you cannot attend some sessions, they will be available later in Salesforce+.


Day 1: Tuesday, September 21 

  • Dreamforce Main Show: Trailblazing Together with Marc Benioff and Special Guests (12:45 p.m. ET)
  • Integrate Everything, Automate Anything with MuleSoft (1:00 p.m. ET)
  • Innovation from Anywhere with Salesforce Developers (6:30 p.m. ET)
  • Create User Experiences with Lightning Web Components (7:30 p.m. ET)
  • Develop Enterprise Applications with Apex (8:00 p.m. ET)


Day 2: Wednesday, September 22

  • A Special Conversation with Co-Founder & CTO Parker Harris (12:00 p.m. ET)
  • Build the Future of Business with Salesforce Architects (3:30 p.m. ET)
  • Architecting at Scale (4:30 p.m. ET) 
  • Unlocking Insights with Tableau (5:30 p.m. ET)


Day 3: Thursday, September 23  

  • Your Roadmap for Connected, Effortless Service (12:00 p.m. ET)
  • MuleSoft: Create Integrated Customer 360 Experiences (12:30 p.m. ET)
  • Fast and Easy Integration with MuleSoft Composer (1:00 p.m. ET)
  • The IT Leader’s Guide to the Salesforce Platform Roadmap (2:00 p.m. ET)
  • Empower IT to Ship Faster with Functions and DevOps Center (2:30 p.m. ET)


Test your equipment. Make sure you have all the equipment ready and prepared for a perfect virtual experience. Test your internet speed, and have a backup source just in case. Also, prepare your laptop and phone chargers as well as grabbing additional cables in advance. You don’t want to have your devices run out of power in the middle of a great session. 


Prepare your space: We’ve all been juggling working from home for months, so we know how easy it is to become distracted. The best approach is to find a space in your home that will let you focus on the event with minimal interruptions. Close that email, for example. We know it’s tempting to multitask; avoid it if at all possible. Give yourself the time to focus on learning and engaging as much as you can. And some of those sessions may be early; make sure you have your favorite brew ready!


Whether it is your first time attending Dreamforce, the second time, or more, we are sure you will have a great experience!

Salesforce DevOps Q&A

Interested in becoming a DevOps engineer, but you still have some questions about it? Sebastian V, an architect in our Uruguay office, has answers.

Salesforce DevOps Q&A

What DevOps tools have you come across? Would you recommend any Salesforce-related products?

There are many tools, but the most useful ones are repositories. Then we have different automation tools based on the Continuous Integration approach. The first tool I used was CumulusCI, a powerful toolset for employees and community collaborators. It allows anyone working on an enhancement to NPSP(Nonprofit Success Pack) or EDA (Education Data Architecture)—or even a community project to spin up a Salesforce instance complete with NPSP or EDA already installed and configured.

CumulusCI builds orgs based on repeatable recipes (dependency management, package or application installation, metadata deployment to tailor org, and more). CumulusCI makes it easy to define fully realized scratch orgs. Also, it has a pipeline, a UML script that lets you determine how you want that deployment to be. For example, suppose you need to add test data or run one specific apex class before the deployment. In that case, you can customize the way that you are going to deploy.

Jenkins is the second tool I have been using. Jenkins is a free and open-source automation server. It helps automate software development related to building, testing, and deploying, facilitating continuous integration and continuous delivery. You can integrate it with different tools, like Slack, GitHub, Assembla, and more. It’s an excellent tool. 


Should the production deployment be automated too?

The idea is that we try to automate everything. The thing about production deployments is that sometimes it is an issue because businesses don’t want an automated tool to do those deployments. 

The primary goal of DevOps is to try to automate everything. This is what we call the Value Stream: the process required to turn a business hypothesis into a technology-enabled service that provides value to the customer.


Does CumulusCI use the same SalesforceDX commands?

No, it doesn’t use the same ones. For me, SalesforceDX (SFDx) commands are more difficult to understand because of the way they are written. CumulusCI gives you more human-readable commands, and it lets you create your own commands.


How different or similar are the profiles of a DevOps engineer and developer? Do DevOps engineers need to be a developer first?

In the past, operations teams have had a different role in IT. DevOps is not trying to change that because there are some things that the operation team needs to continue doing, like monitoring. The DevOps profile adds development, so if you ask me, you can start from both sides.

It is essential to mention that being on the DevOps side requires knowing code because pipelines are written with code. For example, Jenkins pipelines are written in a groovy version of Java. Also, command-line tools use shell commands, so it is better if you know how to write shell commands.

So most DevOps engineers must understand and know how to work with GIT, shell commands, and different languages like Java. 


What should I do if I want to get started in DevOps?

You can follow many paths, and there’s the myth that DevOps engineers are the top senior developers, that is not like that. DevOps has a broader spectrum. And, of course, there are DevOps engineers that are awesome!

But if you want to be a DevOps engineer, we are not interested in designing applications; we focus on helping improve the development lifecycle. You can take some great certifications online, like AWS Certified DevOps Engineer – Professional and Certified Kubernetes Application Developer (CKAD). They’re a great way to get started.


How is DevOps different from agile?

That’s the myth that says that DevOps is coming to eradicate agile. That is a lie because DevOps and agile complement each other. Agile focuses on the requirements side and the building part, while DevOps focuses on what comes next – it’s like an extension of the framework. DevOps tries to focus on the value streams, how they can reduce them, and how to automate. So it’s like the next step in the new era of a software engineer. You still need agile, a scrum master, a product owner, and your team. But how do you deliver that to the market? Well, you will have to use DevOps. 


What is the best thing about DevOps?

Our DevOps team keeps growing, so we asked some of the team members for their favorite things about DevOps:

“What I like the most about DevOps is the interrelationship with all teams in general. One is a full stakeholder. The most important thing to know and remember is that DevOps is not a trade, profession, or specialty; it is a philosophy and culture, and it is not only the knowledge about the use of tools. At the same time, a DevOps engineer never stops learning. We are constantly learning new tools and ways of working from different resources. Another exciting thing is the automation of processes to launch servers, monitor them, and generate an infinite number of jobs in this area. I can’t select one favorite tool because I like them all. I use the IntelliJ IDE and Infrastructure As A Code (IAAC) Terraform + Ansible + Puppet + Salt for programming. For CI/CD, I use Jenkins + Github. DroneCI for image generation, for acceptance test Cucumber, and for monitoring Sonarqube.” 

Marco Ramirez – Oktana DevOps, Bolivia

“I like being able to have a precise and efficient process of moving the new ‘features’ implemented to other environments. So later, as a developer, you can focus on the development itself and not worry too much about deploying the new features.”  

Kevin Monzon – Oktana DevOps, Uruguay

If you are interested in learning more about DevOps, read our latest article: Introduction to DevOps and Continuous Integration. And if you are interested in joining our family and following this career path, check out our open positions.

Introduction to DevOps and Continuous Integration

Sebastian V. has been working as a release manager on our team in Uruguay for more than a year. He is a Salesforce Certified Application Architect who most enjoys designing development life cycles that improve development capacity. Helping developers and the whole team to work as comfortably as possible brings him great satisfaction.

In this article, you will learn the main goal of DevOps, why we need DevOps, and lastly, we’ll explore the Continuous Integration (CI) framework.


What is DevOps?

The term “DevOps” combines the words developers and operations, which are typically two different teams in IT:

One takes care of the building process and the other takes care of maintenance. When we say developer team, we aren’t talking just about developers, we must include lead developers, tech leads, architects, and quality assurance engineers. And when we say operations team we are talking about system admins, software configuration management engineers, DBAs, network engineers, and server engineers. Everyone is responsible for deploying the application, maintaining the servers, databases, and monitoring the logs and traffic. 

The DevOps movement started around 2006 in response to the culture of fear that the industry generated. The agile process was great at solving the issues between gathering requirements and building, but the software industry was still dysfunctional. 

DevOps is a framework with a series of preconditions, activities, processes, and tools that are designed to solve and prevent some problems, such as production issues, rolling back incompatible changes, delayed releases, delays going live to market, and total team burnout. It also helps operations teams avoid having complex deployment sessions that are time-consuming because the more time between each update, the more those environments tend to diverge from each other. As a consequence, the discrepancies between the environments will impact the developers, making it more difficult for them to develop new features. To sum it up, these challenges make it harder to get something out to production.


What is this framework about and how can it help to solve some of these problems?

DevOps enables us to simultaneously improve organizational performance and the human condition.

  • End-to-end responsibility

Delivery is a team responsibility. The phrase “it works on my machine” is no longer valid. Developers and the operations team need to take ownership together. Both teams must collaborate from the beginning.

Example: Operations teams could prepare scripts to allow developer teams to work comfortably on their individual environments (automatic deployment scripts, automatic test data load, environment management scripts, for cleaning and cloning). If for any reason there are manual configurations that need to be made, the whole team will be responsible for documenting the changes needed, to make sure that a piece of code can be deployed to any given environment. The quality assurance team also has a primary role here as they will be the first ones to receive a finished piece of code, so it’s a great moment to test the scripts and correct any issues with the deployment activity.

  • Small increments over monolithic deliveries

It’s not easy for many new features to fit on a running server without any errors. Deliveries should be more frequent and with less “density,” meaning fewer features in each delivery. Ideally, we want just one small functional change to be delivered, so we can do it several times during a given period.

Example: Imagine you have an open-source free writing tool that crashes once in a while. You soon realize that you usually save your work when you finish a chapter (every two weeks) but this crash happens once a month, so when this happens you may lose almost two weeks of work in the worst case. You start saving frequently and eventually you end up saving after you finish a paragraph, so in the worst-case scenario, you would only lose one paragraph. This gives you a safer and systematic solution.  The same approach applies to software. If for any reason you need to roll back, you only lose the last change and not the complete release. 

  • Automate everything

We must reduce manual procedures as much as we can. This is where the operations team can help more, by defining configuration scripts, or data scripts that can be bound to the source code so when there is an environment that needs an update, these scripts will do all the preparation and post setup work. Sometimes this level of automation is not going to be possible, but the less manual configuration the better. 

Example: Sometimes it happens that manual configuration is easier and faster than the scripts. Logging in to the environment and selecting an option on the settings menu is easier than creating a script, finding and writing the appropriate code, and finally, testing it. We are often tempted to find the easiest way. But what happens when this procedure needs to be done on every deployment (each server or each environment), after repeating the steps 10+ times, the script will seem the easiest way.

  • Run unit tests 

Unit testing is the key to delivery reliability but developers tend to hate it. We sometimes don’t see the value of creating so many tests, especially that obvious one because it feels almost like losing time. But more often, unit testing is the part that we forget when we estimate a task.
Example: Imagine you only need to add a few lines of code and it will be done. You think it’s two story points for the estimate (story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work.). Then when you write the code, you realize that you could unit test it, and when you dive into it, there are many tests that you need to write, so the task actually required more than two story points.


Continuous Integration (CI)

Continuous Integration (CI) is a development practice where developers integrate working code several times a day and each integration can be verified by automated tests. The word ‘integrate’ comes from the process of “adding the changes.” Working code is the code that passed all tests. If the code isn’t working it can’t be integrated. Also, each integration can be verified, this means that there is a history of these logs going on, this traceability aspect is very important since it can help to track issues and find the exact turning points where defects are introduced.


Continuous Integration goals

  • Easily detect integration bugs 

Sometimes a test that works in our environment won’t work on another. This points out that there are differences between the environments that we need to address. Resolving the differences helps create an environment that is synchronized. It’s important to mention that the more updated tests you run, the stronger the application you build.

There are development practices like test-driven development that are based on this principle. They develop tests before the software is fully developed. Those practices are considered the most reliable way of programming and are the ones that achieve the highest development velocity. Despite the general belief that writing tests slow the developers down, it’s the other way around, because we lose more time trying to find the source of a defect than the time we lose writing a unit test. 

  • Increase code coverage 

Code coverage has been used as a metric that determines how reliable the unit tests are. It is based on a simple concept: if after a test run we have uncovered source code in areas of our application that we are not certain is correct, therefore, there could be unspotted defects. There are platforms like Salesforce that won’t let you deploy code that hasn’t reached a given amount of code coverage, helping ensure you introduce best practices 

  • Develop faster and never ship broken code 

Today, organizations adopting DevOps practices often deploy changes hundreds of times per day. In an age where competitive advantage requires fast time to market, organizations that are still driven by old-fashioned practices are doomed to fail. Two major points make a big impact on development velocity: 

Hand-offs so the deployment can take place. Having to rely on other teams will only make the deployment slower because those teams won’t be prepared and will have to catch up with the task. 

Debugging, when unexpected errors occur, and we don’t have a clue where they come from, fixing and debugging them can take many hours, even days. We know that having a unit test doesn’t guarantee a defect-free application, but it helps in identifying where the issues come from, and we can catch those issues at a very early stage, so fixing them is much faster and we will only promote working code.

  • Consistency in the build process 

Using CI pipelines streamlines the process of product release, helping teams release high-quality code faster and more often and lets us rely on an automated framework that can repeat the process over and over again. This consistency is achieved by reducing manual procedures and hand-offs.

  • Increase confidence in the software

CI is the result of decades of experience and provides value by helping to deliver valuable systems to users faster. It helps to produce a higher quality code base with fewer defects. The severity and frequency of defects drop after adopting continuous integration. This assures that the production deployments will run a lot more smoothly by identifying incompatible aspects earlier, which is critical.

If you want to know more about DevOps and how become a certified DevOps engineer, we recommend AWS Certified DevOps Engineer – Professional. Also, we are looking for developers to grow our DevOps team, and check our available positions

Calling Apex methods in Salesforce Lightning web components

Originally published as ¿Cómo Llamar Apex en Lightning Web Component?


One of the features that Salesforce gives us is the ability to call Apex methods in Lightning web components. This can be done by importing the method and calling it with the decorator wire service or imperatively.

Calling Apex methods in Salesforce Lightning web components

How to import an Apex method in a Lightning web component?

We can import methods from Apex classes into a component using the import form in ES6 (ECMAScript v6). This way:

  • apexMethodName: Symbol to identify the Apex method.
  • apexMethodReference: Name of the Apex method that we are going to import.
  • Classname: Name of the Apex class in Salesforce.
  • Namespace: If the Apex class is in the same namespace as the component, do not specify a Namespace. If the class is in a managed package, specify the namespace of the managed package.


How to expose an Apex method in Lightning web components?

To expose a method of an Apex class in a component, the method must be static and global or public. Also, we need to add the @AuraEnabled annotation to it.

In the following example, we expose a method called getContactList in the component, which returns a list of contacts.



How to call an Apex method with React Wire?

To read data from Salesforce, the Lightning web component can use the Reactive Wire service. The wire decorator is used to call an Apex method.

In the following example, we call an Apex method using the wire decorator.


How to call an Apex method imperatively?

In the next example, we call an Apex method, which returns a list of contacts, imperatively. The imported function returns a promise.

If you are looking for Salesforce technical content in Spanish written by experts, we recommend visiting Snake on Code, where you will find more information regarding Lightning web components, Apex, and more. 

If you enjoyed this article, here are some more that you might enjoy:

Developing Salesforce Lightning Web Components

In mid-2020 we started a project to build small Salesforce components that could be added to any application or even a registration page. That project has grown to include twelve components currently in production and many more on the way. We publish the components on the AppExchange for free so any Salesforce administrator can install them into their org to try them out. Our team builds components that are utilities that can help us on a daily basis, or complement our other work in some way.

Developing Salesforce Lightning Web Components

Lightning Web Components

There are a few approaches we could take to build components like these, but we wanted to take advantage of the newer Lightning web component architecture. It uses JavaScript, HTML, CSS, and the Lightning Design System. When we need to access custom and standard object definitions or build and call REST APIs, we use the Salesforce Apex programming language.

Lightning web components are a powerful tool because they present data to the client in a dynamic and reactive way. Most components are designed to directly support the Salesforce users who will be interacting with them. This approach allows our team to build for desktop and mobile with very few differences in the code structure. And the Lightning Design System is crucial for designing and developing a UI that is consistent with the rest of the Salesforce experience and is easy for the end-user to understand.

Even though all the components are “components”, some of them could be classified as “sub-components”, meaning that one could be nested and work inside another. This allows the team to distribute tasks better and work more efficiently. It also allows the components to be scalable and to add more features to a single component. It also has the advantage of making the work neater: the code is more organized as each component has its own functionality. 


Customer-centered Logic

When creating a component that runs in a complex environment like Salesforce, we want to be sure to minimize the number of interactions with the server. Customer-centered logic helps us reduce response time and to create elements that interact with the client faster. This approach lets the server delegate many of its responsibilities to the browser. Since it acts as a controller, all the user’s logic is handled by the browser.

Developing in this way requires a disposable cache that stores data locally, reducing the response time. The approach is called a “View-Controller-Controller-Model” because it has both a server-side and a client-side controller. Other frameworks such as Visualforce do not interact as quickly with the customer because they continuously consult the backend and request information and/or approvals. They depend 100% on the server. The server has to handle all the user’s requests and analyze what the user needs, then access the database, answer the question, and then render the page for the user. Not very efficient.


Component Ideas

The process of building a Lightning Web Component starts with a brainstorming session. Once all the ideas have been discussed, the team does a reality-check and chooses the most Lightning web component-friendly options. Then a team is designated to research available APIs on the market and determine which libraries they need. It’s only at that stage that we determine if it is feasible to develop that new component. If it is, a designer then creates a sketch with the layout, titles, logo, and color palette, and the development team starts building the components and Apex classes. 

We currently have three Lightning web components published on the AppExchange, including Oktana Calendar and Oktana Youtube, with more components already in the security review process. It takes time for the Salesforce security team to complete their review and approve any app or component, and that review process has become even more rigorous recently. We’re excited to share with you our new components as they’re approved and published on the AppExchange. Keep an eye on this blog or check our Salesforce AppExchange listings page.


Why Become a Certified MuleSoft Developer


Interested in obtaining your first MuleSoft certification, but still have some questions about it? Ana, a developer in our Ecuador office has some answers:


What is the advantage of learning MuleSoft?

The most important advantage that MuleSoft has against other platforms is that it allows you to develop and manage APIs easily. You can even drag and drop components and integrate systems. With MuleSoft Anypoint™ Exchange you can add your APIs to a marketplace to reach a broader audience. That same marketplace gives you connectors that can make your life easier. For example, MuleSoft allows you to use a Facebook or a Salesforce package to integrate systems more easily.


Do you have to be a programmer?

Knowing how to code, or at least understanding how to do it, is useful because it helps you better understand certain topics in the MuleSoft training. For example, DataWeave, try-catch blocks for error handling, and other concepts like that are things you will need to know to be successful.


Do I have to know a specific programming language to learn MuleSoft?

You don’t need to know any specific programming language. But you just have to know how to code; that should be all you need.


How does MuleSoft help companies to grow?

When a company needs to integrate systems, MuleSoft gives them an advantage. With pre-built connectors, MuleSoft makes it easier to connect those systems without having to write a large amount of custom code. Also, if a company wants to produce its own APIs and possibly sell them, the MuleSoft Anypoint Platform makes that easier. They can even use Anypoint API Community Manager to create a Salesforce Experience Cloud community for API developers, which can help quickly grow adoption for the APIs.


Are there any prerequisites before someone takes the MuleSoft developer certification Level I certification? 

It’s important to understand programming and knows a bit about APIs, like what they are, how they’re used, and why you’d use them. MuleSoft certification is not very difficult as long as you know your basics. 


It is possible to achieve the MuleSoft developer certification by myself?

Of course, it’s possible. And it’s a great opportunity since the course is free. To start, go to the training page and sign up. If you pass the training, then the exam is free.  You should take advantage of this opportunity! Just remember, you need some experience with coding to know the terms and to understand DataWeave. It shouldn’t be too challenging for you.


What is the best API?

Which API is best depends on the project you’re working on. So maybe, if you want to incorporate a map in your system, consuming the Google Maps API would be the best solution for you (if it complies with all the requirements you need to meet).


What is the next step after you earn the MuleSoft developer certification Level I – Mule 4?

After you achieve your certification, your next step could be to go for the  Integration Architect certification. In my case, I want to gain more experience with MuleSoft projects before I become a certified Integration Architect. For that certification, MuleSoft has training that can help you, but it is not free. 


How long does it take to get MuleSoft developer certified?

That’s a great question, but it really depends on you. You could finish this course in five days if you are 100% committed, but you can also use other kinds of resources. Just to be sure you are ready before you take the exam. So it could take, five days, one week, or two weeks, it all depends on you and the time and effort you put into it.

Here are some great resources that helped me: 


In which kind of projects can I use MuleSoft?

You will use MuleSoft only for projects that require integrating systems. For example, if in your project you integrate a database and then you want to use that data in another system, you can use a specific API for that. But it really depends on the project and your requirements.


As a front-end developer, do you think it is useful? or is it only used in the back-end?

I think that as a front-end or a back-end developer it could be very useful to have a full understanding of what MuleSoft can do. So it’s worth getting this certification to give yourself a better understanding. As I said, this is a huge opportunity and the exam is free,  so you must take it!

If you want to know more, watch the webinar about MuleSoft certification and Ana’s experience.

Interested in learning more? Check out some of our latest MuleSoft articles:

Why Connect your Apps to Salesforce

Founded in 2014, our focus here at Oktana is to help customers integrate their systems with Salesforce, whether through custom development or integration with third-party services. Our onshore and nearshore Salesforce experts have certifications across a wide range of products in addition to Salesforce, like Informatica (Informatica Specialist Certification) and MuleSoft (MuleSoft Certified Developer – Level 1, Mule 4 Certification).


We have helped our customers integrate their Salesforce ecosystem with almost everything. Our experience ranges from complex data migrations to building personalized user experiences, enabling companies to connect and leverage data of any kind to create a 360-degree view of their business. Across multiple industries, we have helped our customers integrate with technologies like Facebook, Amazon Web Services, Microsoft, Bevy, Instagram, Twitter, Google News, LinkedIn, Webex, Gotomeeting, MuleSoft, and many more. Read more about Oktana’s Salesforce Integrations stories.

The idea of integrating with Salesforce is to make your Salesforce CRM experience even better. Uniting information into personalized views helps users and managers make better decisions. In other words, connecting Salesforce with apps and tools that you already use helps you run your business more efficiently and provides much greater operational visibility.

For a Salesforce integration process to go smoothly it is important to understand your business goals, create a fool-proof plan, and provide training for your team to make the most out of your Salesforce integration services. 


What are the different types of Salesforce integrations?

1. App-Based Salesforce Integration

The vast majority of organizations use Salesforce to manage data, develop leads, and provide effective customer service. Numerous third-party apps are integrated with Salesforce to streamline the CRM by providing business applications and reducing data duplication. This includes integrating apps from the Salesforce AppExchange. At Oktana, we’ve built and managed several Salesforce AppExchange apps including one of our own, Tok for real-time communication with Chatter.


Tok - For real time communications


Also, we have worked on implementing MuleSoft solutions since it was first acquired by Salesforce and we are experts at customizing and integrating the new Anypoint Platform™.


2. Code-based Salesforce Integration

Salesforce integration can also be done using programming languages. Apex is the default Salesforce programming language that has Java-like syntax. There are numerous advantages of using Apex, the most common ones are that it is easy to use and test, it is hosted on the Lightning Platform, and offers built-in support.

At Oktana, some of our senior staff have more than 15 years of experience programming with Apex.  We’ve worked on projects that required using APEX to make API calls to external systems, allowing access to information that they needed in their Salesforce org. Integrating this way can sometimes be the only option, but it can be more work to maintain than leveraging an app-based integration.


What are the possible ways to integrate with Salesforce?

Integration typically occurs within 3 different areas: user interface (UI), business logic, and data to provide a greater level of operational efficiency, standards, and consistency to users.


1. User Interface Integration

A great way to permit users to enter multiple apps from a single platform. One such example is the Facebook or Twitter apps. Publish tweets, send messages, and follow others on Twitter automatically. Sync contact data, manage deal flow, and automate your sales pipeline in Salesforce.


2. Business Logic Integration

Use Apex to handle business logic across multiple applications. It helps extend the business logic present in with outside platforms. Apex web services are used for inbound logic integration, to write logic and express it as a web service for external applications. It provides developers with the ability to apply project-specific business logic and the flexibility to add custom logic. 


3. Data Integration

Handle data synchronization needs by using SOAP and REST APIs to allow a single application in an enterprise to act as the primary source of a specific business object. 


Salesforce Integration Checklist


Salesforce Integration Checklist


1. Planning & Documentation

Planning and documentation of the assigned project are required to find additional insight into business needs and technical requirements for the project. It should include:

  • Write down the business goals
  • Identify data ownership
  • Understand integration standards & best practices

2. The Apps

The application is the most important part of any integration scheme and is vital for the successful accomplishment of the work. It is crucial to understand the apps and how they integrate. It must include:

  • Prepare the data 
  • Understand the dependencies for each application 
  • Enable APIs
  • Consider API limits

3. The Processes

Processes establish the flow of data from one endpoint to another, which helps in staging and modifying data before transmission to other applications. 

  • Identify the endpoints
  • Provision of effective connection for custom integration & 3rd party integration tool
  • Determine data delivery performance for applications
  • Limit and control access to trusted users

At Oktana this is just one of the services that we provide to our customers. If you are looking to boost your business success and profitability request a quote from our Salesforce integration services page. If you would like to be part of our team of Salesforce experts, check our careers page and apply for the job that best fits your skills.