When was the last time you took stock of the custom code in your Salesforce org? If it's been a while, now might be the time to check on your triggers. Older Salesforce orgs may have evolved to include more than one trigger per object. This can cause unpredictable behavior, which is never a good thing. Does your Salesforce org have too many Apex triggers?
Cloud computing, with its related software, platform, and infrastructure service models, has changed the way people use technology. It's so common that many people don't think about, say, webmail or online document sharing as a cloud computing service; it's just a normal part of the landscape. Both individuals and organizations use many cloud computing services. While Salesforce CRM is a widely used software as a service (SaaS) product, Salesforce also offers its Force.com platform in the PaaS (platform as a service) space. Is Force.com a real PaaS?
Sooner or later, in the Salesforce ecosystem, you will find yourself writing code to customize a Salesforce organization. There are plenty of references about the Apex programming language, which is Salesforce's Java-esque proprietary language for controllers and triggers. Of course, you'll follow general programming best practices. You'll also want to keep a few things top-of-mind about Salesforce coding.
So you want to build a mobile app. Should you choose native or hybrid mobile application development? Each choice has advantages depending on your projected use and time to market.
What is a hybrid mobile application?
Mobile apps generally fall into two categories, native and cross-platform or "hybrid". A native mobile application is just what it sounds like: it uses the SDK (Software Development Kit) and hardware features specific to a particular mobile operating system. Hybrid mobile applications also fall into two general categories, hybrid HTML5 apps and native cross-platform apps.
Salesforce User Adoption, Part II: Improving Salesforce User Adoption
Creating a great Salesforce app for your team is only part of the solution; the other part is getting your team to use the app. The best tool in the world is useless if it's not used! You've seen plenty of tips about signs your team has bought into using Salesforce. Your next step is improving Salesforce user adoption, and communication, training, and continuous refinement are the keys.
Writing software requirements should be easy, right? Right? Of course we know exactly what we need and can tell you exactly what the software should do.
Unfortunately, it's not always so easy. Writing software requirements well takes detailed, deep thought about business requirements. It also takes clear communication between the people who will use the software and the people who will write it.
It isn't always easy to translate between business-speak or industry-speak and developer-speak. This can cause costly confusion. Fortunately, there is a language called Gherkin to help bridge the gap.
So what makes a good set of software requirements, and how can we develop those requirements?
You may have heard software developers and project managers talk about "technical debt". This term has been around since the 1990s and is growing in popularity. But what is technical debt and why do people keep talking about it?
Legacy system conversion projects are always challenging. Rollout strategy can make a huge difference in successful user adoption and overall project success.
Only when I began writing them down did I realize that I had recurring dreams. I had believed that my dreams were largely random and varied, but instead I learned that I had many frequently recurring themes. Similarly, the process of writing down my thoughts on software development has shown me that there are also recurring themes.
One of these themes is the impact of rollout methodology on a project's success. More specifically, rollouts of legacy system conversion projects. Rollouts of brand new systems into an organization are typically less painful, as you are often automating a paper process, or inventing a new process that improves productivity. However, legacy system conversions are almost always painful, as there are many processes that have emerged around this system. People have developed a form of muscle-memory with the old system that even they themselves scarcely understand.
We have successfully replaced dozens of legacy systems where everyone was happy and all was good with the world. But it's not those projects I want to talk about. I am going to talk about the projects where things went awry, because I don't want to make the same mistakes again. Hopefully, these words will also help the reader to avoid similar problems in their projects.
Working with Salesforce relationships is a little different from traditional relational database structures, but Salesforce has great tools for building custom data relationships and most people can adapt quickly to the SOQL model. As with any other system, though, there are a few "gotchas" to watch for when designing Salesforce relationships. I ran into one of these gotchas just recently. I needed a lookup relationship from our custom object to the standard Product table, Product2. No problem, right? Create the lookup field in the custom table, and there it is. Not so fast!
It's a funny thing about Salesforce developers. Many of us really dislike change, even when we know very well it's necessary and worthwhile.
Why? Too often, changing an application is like re-routing plumbing after the house is built: making a change that looks small can take a whole lot of effort with a whole lot of risk for collateral damage.