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?
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.
The basics are in place: you've set up your Salesforce org, and you've customized it enough to let your sales team work pretty efficiently. Now your users are asking for more. They want more automation to streamline their work, more customization to tailor their experience to their needs, more built-in business logic to improve the quality of report data. How much of this can you realistically do in-house? Is it time to outsource Salesforce work for your organization?
How organized is your purchasing system? If you're not already using purchase orders, it may be time to start. If you are using them, take a moment to evaluate how well your off-the-shelf software fits your current needs. It may be time for a custom purchase order system.
Why should I use purchase orders?
A formal purchase order process has a lot of benefits for both buyers and sellers. Here are a few:
In today's connected world, consumers want to interact with service providers on their own schedule and receive individualized information and experiences. The same principles apply to citizens, who are the "customers" of their government. Citizen-centric government using public portals is a growing trend. These portals offer citizens secure, convenient, and personalized channels to interact with their government and offer civil servants greater efficiency and deeper insight into the needs of their citizenry.
Now that you've implemented Salesforce and your team is reaping its benefits, it's time to step up your game. You're already rocking the CRM, streamlining the sales process, and using rich reports as feedback to keep on fine-tuning your sales machine. What's next? Your business processes. Here are some ways you can use Salesforce automation to improve business processes.
People who work in nonprofit organizations want to spend their time and energy on their primary mission, not entering data into a database. Unfortunately, nonprofits really do need to use some kind of database to manage relationships with their donors and their beneficiaries. From a human perspective, managing donor relationships is not much different from managing customer relationships. Managing your contacts in a spreadsheet might work when you're just getting started, but you'll do much better if you use a true Customer Relationship Management (CRM) system. The Salesforce Foundation makes it possible for you to cultivate donor relationships for little or no cost.
Many companies use Salesforce not only for sales-related CRM but also for managing disparate business processes. Salesforce record types can help administrators fine-tune their orgs and manage business processes for different users effectively.
Sometimes, administrators go a little overboard with custom record types. Even after reading the documentation, it can help to see how other admins utilize Salesforce record types. Here are some tips to help get you started.
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.