Your web browser is out of date. Update your browser for more security, speed and the best experience on this site.

Update your browser
CapTech Home Page

Blog May 17, 2018

You Don't Need Apex Developers to be a Successful Admin!

Adam White

Cloud technologyWhen faced with a complex new business problem, you might be tempted to believe that you need an army of developers, but you would be amazed what you, the lone admin, can accomplish without ever touching a line of code!

When you're the sole admin for an organization with little or no coding skills, you typically place a heavy premium on solutions that utilize Salesforce's out of the box functionality, or relatively inexpensive 3rd party plugins. It's important to evaluate your technical environment before picking a solution. If you have permanently staffed developers with a strong DevOps process, it may be okay to code! Many admins do not have that luxury, so here are some of the most common 'Must Code' use-cases, and some non-code approaches to solving them.

Gathering Input from People Outside Salesforce Through Forms

At some point you will likely want to gather data from a customer or stakeholder and then have that data make its way into Salesforce. Two of the most common examples are gathering survey feedback and a 'stay in touch' form that lets Contacts provide you with updated information.

During development public forms get complicated quickly, and suddenly your requirements balloon. You suddenly need complicated logic, lookups, and other fun automation to happen within the form. The typical approach is to write custom Visualforce pages exposed through a Salesforce 'Site' or public Community. This usually involves a developer writing the HTML, writing custom apex 'controllers' to access data, and a lengthy and sometimes painful deployment process to make it all live. This takes away valuable cycles from your developers, or in your case, the money you've budgeted for external help.

We've worked with two companies that we're huge fans of: Form Assembly and Formstack. Both solutions allow you to quickly and easily create webforms that you can embed in your Salesforce community or hosted on their website. You can then map form fields to Salesforce fields and do some awesome stuff like creating or updating records for any object, pre-filling data from Salesforce records, and perform conditional logic within the forms. You can even send data to multiple orgs, provide eSignatures, and make payments!

While the monthly cost can get somewhat high for the higher tiers, if you're creating many forms it is well worth it. Offloading form development to non-developers frees up valuable development time or contractor dollars that could be spent on other efforts.

Writing 'Triggers' to Roll Up (or Roll Down) Information About Related Records

One of the trickier and unfortunate limitations of Formula Fields is that you can't do complicated rollups of information about related records. In Salesforce you need to have a Master-Detail relationship to do rollups of 'children' records, and even then, there are limitations.

Unfortunately, the majority of relationships in Salesforce aren't Master-Detail, they're Lookups! The most common way of summarizing 'Lookup' related records is by writing Triggers. The typical approach is to write a trigger (on any Delete/Create/Update event on an object) that then runs a SOQL query to grab other related records and then summarizes the data on the parent record. You then have to run it nightly using Scheduled Apex Jobs if you want it to stay accurate, mostly if you're rolling up a date field. This can fall apart quickly if you want multiple rollups with various developers working in the code and can lead to a number of Salesforce-imposed limits being reached.

Enter Rollup Helper!

One of the best plugins out there to have in your admin tool chest is Rollup Helper. Rollup Helper allows you to 'roll-up' information into a custom field from any related record (both children and parent records) and display it in real-time. This can then be used for HTML Email templates, Workflows, and Reporting. You can also manage update schedules, real-time rollups (Paid Version), and migrate Rollups across environments.

Here are some typical use-cases, and then a more specific example:

'Simple' Use Case

'Specific' Use Case

Count the number of Contacts tied to an Account

Show the name or Contact ID of the Contact listed under the 'Technical' role on the Account to easily identify the technical point of contact.

Count the number of past due tasks assigned to each Account

Roll up the date of the most recent Task logged by a user on an Account to drive a Workflow that alerts the Account Owner that they haven't engaged that Account in over X months.

Count the number of open Cases on an Account

Display in a semi-colon separated list the Case Owner names of all the unresolved High Priority Cases tied to an Account

The possibilities are endless and I always hesitate to give a laundry list of examples because it really comes down to how your Salesforce instance is structured. I cannot recommend it enough.

Avoiding Visualforce Emails

One of the greatest weaknesses of creating an HTML e-mail template in Salesforce is that you cannot reference fields of related records or perform complicated logic like you can in a Formula. Sometimes Visualforce Emails are unavoidable, but you do have options! Here are a couple 'must code' situations that require complex Apex data controllers, Visualforce e-mail templates, and a required deployment from a Sandbox to Production for any change to the underlying data being accessed:

  1. You want an e-mail that summarizes and lists out every case that is tied to an Account.
  2. You've got a Project-Milestone-Task object structure, like Milestones PM+, and you want to send an email out that summarizes a list of all tasks that are Complete and Past Due

Here are a few paths you can take when trying to create complex e-mails:

  1. When you want single field values of a single 'related' record: Create formula fields on the 'source' object to pull fields from related records. Say for example you're creating a template with 'Case' as the source record, but you need to reference the value of a couple related fields on the related Account. Simply write some cross-object formulas and ¡Viola! You can now use them in an e-mail template!
  2. When you want small pieces of multiple related records in the email: Use Rollup Helper from the previous example to create text fields containing pertinent information about related records (children and the parent). This is super handy if you wanted to generate an email with a list of related case numbers to a given contact or account. Just roll up all the case IDs into a comma-delimited field on Account and you'll be able to use it in a normal HTML email.
  3. When you want to list A BUNCH of information about related records: Use the plugin Conga Composer, a third party Appexchange product. Conga Composer allows you to generate PDF, Word, Excel, Powerpoint, and E-mail templates from any data within Salesforce. Need to generate a weekly Sales E-mail using Salesforce data that spans objects? Look into Composer.

We hope you found some of these quick tips! While this wasn't meant to be an all-encompassing guide for avoiding code, it should give you a nudge in the right direction if you're stumped in one of these 'must code' situations.