Don't go just yet!

Enter your email below and receive this free offer.

5 min read

6 Things To Consider When Building Salesforce Apps

By Praecipio Consulting on Jul 18, 2022 10:01:00 AM

To keep up with the fast-paced digital landscape, businesses depend on software for carrying out day-to-day business operations, connecting teams, and simplifying workflows. This probably explains why the global application development software market is anticipated to reach $733.5 billion by 2028.

After helping some of the world’s leading brands drive business innovation with our custom software solutions, we've learned a thing or two (or six!) along the way about building custom software that keeps teams and their tools connected. Specifically with Salesforce, our applications and integrations (whether those be specific customer use cases or general ones via the Atlassian Marketplace) have brought systems together, increased productivity, and empowered sales teams to win more deals

Through our experience with developing custom solutions for the world's leading CRM platform, we've identified some key things to consider to help get you started when building Salesforce apps.

#1 – Hit the Trail(head)

Salesforce is a big, well-established environment. There’s a lot you need to know about the REST API, the development process, and packaging and distributing your applications. The Salesforce Developer Training available at https://trailhead.salesforce.com provides free training courses along with sandbox environments to do the exercises. It’s a great way to quickly come up to speed on the topics you need to know more about.

The courses are not limited to development topics. If you need to learn more about using Salesforce or just want to understand the ins and outs of the Partner program, the Trailhead is the place to go.

#2 – The REST API is nice

The Praecipio Consulting development team does a lot of integration work, helping our customers improve their workflows by connecting different systems together. We work with many platforms, and have seen many APIs that are REST in name only. Often these are thin wrappers over an older XML API, or they don’t handle relationships in a RESTful fashion. Salesforce gets it right. The API is clean, consistent, and easy to use.

The API also provides a lot of useful metadata, which can help you make your software exceptional. When working with any object, you can get a list of all of the object’s fields, the labels for those fields (which may have been customized or localized), each field’s type, and whether a field is required or not. For any field whose value is selected from a list, there is an API call to return the list of valid values for the field.

#3 – Leverage a library for your stack

While the API is well-designed, it is large and feature-rich. Starting from scratch can be daunting, and you might not even be aware of some of its features. Instead of rolling your own code, take advantage of open source projects that wrap the API in your language. To achieve this, we use the Restforce Ruby GemSimple Salesforce is a well-regarded Python customer, and jsforce is available for JavaScript developers.

#4 – Deploy with the force (CLI)

Books, tutorials, and Trailhead courses on Salesforce development typically have you developing in the Salesforce GUI. There are times when that is valuable. The Developer Console provides a REPL that is handy for testing out ideas and debugging problems.

However, if you are like most developers, you have invested a lot of time getting your development environment just the way you like it. Fortunately, it is possible to integrate the Salesforce development process into just about any workflow. The folks at Heroku, a Salesforce company, have developed a Command Line Interface called Force, that allows you to interact with Salesforce using an API, instead of the GUI. You can upload and download templates and code, test snippets, view logs, inspect and change settings, plus much more. You can do just about anything you could do in the Salesforce GUI and while doing it in a scriptable, repeatable way.

#5 – Not all Salesforce instances have API access

Salesforce offers a number of editions, each with different pricing and features. One of the features that is not available on the lower cost plans is API access. Trying to access the API of an organization with the Contact Edition, Group Edition, or Professional Edition will raise an error. It’s also possible for the administrator of other Editions to turn off API access. Full details can be found in this article.

However, it is possible for a developer to get API access in these editions, which bring us to our final expert tip.

#6 – Managed packages and unmanaged packages. Choose wisely.

One of the topics that can be confusing for new Salesforce developers is Packages. It’s an important topic to understand because your choice can limit who can use your application and how.

Packages are ultimately bundles of customizations created by you that other Salesforce users can install into their organization. You customize a Salesforce instance and then, using a Salesforce-provided tool, you package up those customizations and publish them.

Once you have created a package, you can simply share a link to it. This is then considered an Unmanaged Package. Alternatively, you can submit that package to Salesforce for review, after which it will be published as a Managed Package, available in the Salesforce AppExchange.

Pros of Unmanaged Packages

  • Free to create.
  • Can be released at any time.
  • You can sell them directly to your customers.

Cons of Unmanaged Packages

  • Not in the AppExchange, you have to market directly to your potential customers.
  • Some companies will not install Unmanaged Packages, preferring only Salesforce approved applications from the AppExchange.
  • As noted above, API access is unavailable in some Salesforce Editions.
  • No automatic upgrades. If you make changes, your customers will have to manually install the new version.

Pros of Managed Packages

  • Customers can find you in the AppExchange.
  • Automatic upgrades are available.
  • Salesforce manages payments and licensing.
  • Full API access for all Editions. Editions of Salesforce that are not normally allowed to use the API are granted access for Managed Packages.

Cons of Managed Packages

  • Setup cost. The review process for a Managed Package includes a security review, which is expensive and time consuming. If your application will be free, this fee is waived, but you still must complete the security review.
  • Review time. The initial review process can take several months.
  • Salesforce takes a percentage of all sales through the AppExchange.

Ultimately, it’s a business decision. If you want to be in the AppExchange or have API access to all Editions of Salesforce, then you will need to have a Managed Package. However, if you want to move fast, sell directly, and avoid upfront costs, then an Unmanaged Package may be for you.

What's Next?

Still feel like you need some guidance on your custom development initiative? The award-winning team at Praecipio Consulting can bring our Salesforce expertise and software development best practices to your next project. Let us know how we can support your organization and help design innovative solutions that scale with speed of your business.

Topics: rest-api salesforce workflows integration software-development custom-development
3 min read

7 Steps for a Painless SVN to Git Migration

By David Stannard on Sep 10, 2021 10:24:00 AM

2021-q4-blogpost-7 steps for a painless SVN to Git migration

Praecipio Consulting is frequently asked about migrating from various software version control systems to Git-centered tools such as Atlassian’s Bitbucket. Excellent news time: this is definitely possible and can be done in a painless fashion! Some organizations confidently plan and migrate by themselves. But … there’s always a “but” … be forewarned - there isn’t an “easy” button. Your success depends upon investing the effort, both in planning and in communicating with your teams. However, many organizations prefer using experienced 3rd parties who will focus on doing something not considered an organizational core competency. Praecipio Consulting often assists clients in their migrations: our approach is based upon proven tools and processes honed by multiple engagements over the past 15 years. 

Nonetheless, there still isn’t an “easy” button and the client’s involvement is integral to the final outcome as unique aspects are often uncovered.

If you still use Subversion - also known as SVN - as your software version control tool, you can be forgiven in believing that you’re alone. Searching the web yields many documents from circa 2012 which often containing phrases similar to “… 90% of developers have already migrated to Git …”. However, as recently as 2018, literature also indicates that SVN is still used because its users value its strengths over Git.

So say your organization has a business need to switch from SVN to Git. This might be because your organization has distributed development teams, or maybe the usage of SVN negatively impacts attracting new developers who expect a distributed version control tool such as Git or Mercurial.

Bottom line: you need to adopt Git and also migrate some or all of the information contained in SVN to Git; this blog assumes this means a codebase.

To better understand the implications of a migration - I suggest Stefan Holm Olsen’s explanation. Stefan led the migration of an 11 year old SVN, commercial grade codebase to a new Git codebase. All while continuing active development (https://stefanolsen.com/posts/migration-from-subversion-svn-to-git/ and https://www.atlassian.com/blog/git/atlassian-svn-to-git-migration-technical-side).

Atlassian documents a simpler case of a single SVN subfolder being migrated to a new Git repository (https://www.atlassian.com/git/tutorials/svn-to-git-prepping-your-team-migration) This may be sufficient for some do-it-yourself organizations.

In either case, it helps that the migration team understands how Git works and also the differences between Git and SVN. (If not, I suggest a quick detour to https://docs.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github/what-are-the-differences-between-subversion-and-git and https://git.wiki.kernel.org/index.php/GitSvnComparison.) Most software engineers and developers are already familiar with Git - hence the examples address the potential SVN knowledge gap.

Stefan described a 5-step general process. The following 7-step process results from adding a preliminary step, because similar to Agile, the human aspect is primordial. Having an internal champion or two will certainly help increase the odds of a successful migration. An intermediate Git repo step is also added, although the brave may choose to go directly to the final destination. Like any undertaking, communications and scheduling are critical.

  1. Plan your migration including the often overlooked human considerations:
     - What can remain in SVN? What can / can’t be lost?
     - Understand the impact to release notes and governance
     - Identify the impact to your CI/CD environment
     - Determine the timing of the actual migration (weekend, overnight, etc)
     - Train users on how to effectively employ Git
     - The comms plan: who’s communicating, how, and the regularity of the updates
  2. Identify users and their correct names pre & post migration
  3. Choose a location for your Git repository
  4. Prune the SVN codebase
     - Address multiple folders in SVN repositories
     - Thoughtful pruning of folders, files, old and unneeded branches
  5. Create an intermediate repository to support the migration
  6. Migrate from SVN to the intermediate Git repo
  7. Migrate from the intermediate Git repo to the target production repo

Migrating from SVN to Git should not be feared. There are known processes when migrating from source code systems. Some planning and a lot of communicating will go a long ways towards a successful migration. If you need an expert hand in planning and executing your migration, contact us, we would love to help!

Topics: blog best-practices migrations plan repositories svn git custom-development
2 min read

Should Stories & Bugs Follow Different Workflows?

By Joseph Lane on Mar 31, 2021 10:07:00 AM

Blogpost-display-image_Should stories and bugs follow different workflows-The short answer: Not really. Stories and bugs are both software development items by different names. As such, the vast majority of activities and controls that we model for a story are applicable to bugs. The key distinction between stories and bugs often comes down to data. Bugs should include Affects Version/sSteps to Recreate, Expected Behavior, and Actual Behavior. How and when we require this data relies on what practices we're observing.

For teams using Kanban practices where there is a Backlog status and a Ready for Development status, the transition to Ready for Development can be used to capture required data based on issue type. In this simple case, we would have two transitions from Backlog, Ready for Dev and Ready for Dev - Bug. For each transition, include a transition-specific screen to capture the appropriate fields.  Example: SDLC Ready for Dev - Bug Transition Screen will include: Affects Version/sSteps to Recreate, Expected Behavior, and Actual Behavior in addition to any other fields needed in both cases. Then, leveraging your workflow conditions allow the Bug issue type to only use the Ready for Dev - Bug transition. All other issue types can default to the Ready for Development transition by explicitly checking that the current issue type is not a bug.

The considerations above work well in workflow cases where you have gated controls as a function of status change. This might apply to teams that include requirements definitions and design efforts within the story or bug life cycle (as might be the case with Waterfall). Additionally, this logical approach allows for workflow reuse which in turn decreases administrative burden and increases process consistency.

Scrum teams view Ready for Development a bit differently. Good Scrum practices dictate that product owners will refine their backlog as items are prioritized upward. Refinement provides all functional details necessary for the scrum team to be able to work the ticket including validation of bug reports and associated details. Once prioritized, the development team will review stories and bugs at the top of the backlog to make sure they understand the requirements. The work is considered Ready for Development at the moment it is accepted in to a sprint.

I hope this explanation helps you avoid unnecessary workflows!

Topics: blog best-practices bugs kanban scrum workflows software-development custom-development
2 min read

Affects Version vs. Fix Version in Jira: The Difference

By Jerry Bolden on May 12, 2020 9:15:00 AM

2020 Blogposts_What’s the difference between Affects Version & Fixed Version-

In today's post, we'll address the age-old question: which came first, the Affects version (egg) or the Fix version (chicken)?

Both of these fields are automatically created in Jira out of the box. They are related to Software Development Life Cycle (SDLC) projects and are the foundation of releases in Jira. While they are linked and work in tandem at some points, there is a best practice when using the versions inside of both of these fields. Before we delve into how they relate, let's define what each field is and how to properly utilize them. 

What is Fix Version?

Fix version is the release version used to track different software developments and/or any updates. You fill out the Fix version to ensure that as you develop stories, and you can group them together when setting up a release delivery. This release could contain multiple issues created to serve different client needs, and this is designed to help each development team and PO (product owner) track all code to be released at one time. 

What is Affects Version?

The Affects version allows you to track bugs or defects that exist in already-released code. The bug will have a new Fix version on it, which will designate the code release where you can find the solution. Additionally, you can query off of this field to identify which code is having problems after its development and scheduled release. 

Which Comes First?

Now that we reviewed definitions of each version, we can answer the age-old question from the beginning of the post: which came first? In this instance, the Fix version (chicken) comes first. Not only does it group issues together for release, but it's also a way to use the Affects version field properly and efficiently. Without the Fix version field, the Affects version field cannot tie any detected issues back to the respective code releases.

When using these fields, start by tracking releases through the Fix version field first, then use the releases to connect any bugs you found to the Affects version field. This does not stop anyone from using a new Fix version on the bug issue and linking it to a new code release.  

I hope this information will settle any office disputes about which comes first! You should now be able to communicate through examples with Jira. Think about it this way: if the egg came first, the system would be ineffective, so the chicken most definitely came first. If you want to have a friendly debate about this age-old question or discuss anything related to Jira and/or software development, reach out to us!

At Praecipio Consulting, we pride ourselves on being able to work with your team in a variety of ways to help you meet your goals. To learn more about the services we offer, visit our Consulting Services page, and check out the process frameworks we specialize in, like DevOps, ITSM, ESM and more.

Topics: jira blog sdlc tips jira-software custom-development

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

Atlassian-Platinum-Solution-Partner

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us