The first step for a successful integration is understanding the goals, planning and documenting the current processes. The most important thing is to understand the stakeholders and what they need to do with the data.
Moving data between systems consistently through an integration can be difficult especially given all of the limits that Salesforce throws at us!
The purpose of this blog post is talk about all of the common reasons that a Salesforce integration could fail.
When we integrate something we are connecting two applications or systems together so they can talk to each other and share data.
There’s a lot of business benefits to integrating Salesforce with other systems whether it be your enterprise resource planning system (ERP), your accounting software (Quickbooks, Simply Accounting, etc), or even your case management system.
Salesforce has really transformed a lot of companies I’ve been involved with because it’s made the sales team way more effective and allowed all people that need access to know what’s going on.
Integrating Salesforce with other apps has the potential to dramatically improve efficiency and productivity in businesses.
SOAP is basically an XML based API that existed before the REST API existed. SOAP stands for Simple Object Access Protocol – it’s a mostly legacy protocol that was designed for doing remote api requests in a language independent way.
From time to time unfortunately, we’ll need to call a SOAP API.
Release notes are usually written in the present tense and provide details about any changes in a new software version.
The big reason to implement an enterprise resource planning platform like NetSuite is to be able to make data driven decisions. In this post, we look at the different “reporting” tools available in NetSuite.
Having your application / system produce the right amount and quality of logs is just as important as having the system process the needed data because it helps make debugging easier and allows us to better optimize data.
Logging on AWS lambda can be really costly if it’s not done correctly.
Cloud computing is basically using servers whether they be for databases, storage, application or something else through the internet.
Cloud computing’s inherent strengths are elasticity, ability to automate infrastructure management, enhanced reliability and reduced cost.
In my everyday life as technology leader (“tech lead”) and full stack developer I run into a lot of problems that need to be solved every day.
TDD is a lot more than vanity metrics like the percentage of code covered by tests. Test Driven Development (TDD) is a development process that consists of the tests being designed and written before most of the code is written.
Excel is a really commonly used spreadsheet program that lots of companies use to transmit data. Finding a really good library that doesn’t require Excel to exist on the server can be really hard.
Salesforce orgs tend to become cluttered with technical debt and functionality that is no longer being used. The longer the technical debt and unused functionality is allowed to exist the more expensive it becomes because of confusion, complexity, and potential project delays.
In this blog post, we have a look at how to identify technical debt and how to begin removing it.
Developing locally makes a lot more sense than deploying to a dev environment consistently because it helps save time, save some cloud costs, and avoids obvious embarrassment. 🙂
Prettier is a code formatter that can automatically format code when save is pressed. I like using prettier to format my code because it saves me a lot of time and a lot of energy.
A code review is having someone other than the author check someone else’s code for errors or mistakes. Code Reviews are a great time to share knowledge, and learn from one another. I find that often code reviews have a lot of really common mistakes that make them a less effective.
Martin Fowler defines refactoring as “Refactoring is the process of changing a software system in such a way that it does not alter the external behaviour of the code yet improve its internal structure.” I like to define it as “Refactoring is a systematic process of improving code without adding or taking away functionality…
Dealing with technical debt is one of the greatest frustrations and demotivaters to development teams. Technical debt is accumulated through out the software development lifecycle. Over time, the code becomes less and less clean which results in making changes more and more difficult.