Salesforce Security & Visibility Design Considerations

I felt compelled to create a Salesforce Security & Visibility Design Considerations matrix to synthesize and expand on the information presented in the Design Considerations training module, part of the Building Applications with Force.com - Part 1 course. We already have a similar template internally in my company, but creating one from scratch and adding to it on my own feels like a good way to internalize the knowledge.

The matrix focuses on two aspects: object security and record visibility. Specifically, who has permissions to do what with each object, and who can see what records in each object.

To control the "doing", the most straightforward way is to use object permissions with profiles and permission sets. However, it is conceivable that less admin-friendly and user-friendly options can be used to prevent certain operations. Below are a couple of examples:

• A validation rule can be used to prevent editing closed opportunities
• A Process Builder process could fire an autolaunched flow that reaches a fault condition, causing the create or edit operation to fail. Although I doubt anyone would do this right now, not only because it's cumbersome to implement but also because the error presentation in Spring '15 is not very pretty.
• An Apex trigger can be used to add errors to a record, thereby preventing the create, edit or delete operation

To control the "seeing" of records, the only practical means are to use the role hierarchy, teams (where applicable) and sharing rules. However, I do want to point out one technically possible way to restrict visibility in the UI, and that is to use Visualforce page overrides for standard actions. A Visualforce page could use the init action to route the user to a different page based on record and user criteria. While in theory the approach would work, in practice the override would fall flat because of incompatibility with Salesforce1 and because users can create reports or list views to see the "hidden" records.

Alternative to "Designing Applications" Module in CTA Study Guide

The CTA Study Guide recommends the following three DEV-401 modules: Designing Applications, Data Management, and Enhancing the User Interface Using Visualforce. However, upon checking the training catalog I couldn't find an online module titled "Designing Applications".

Searching for "designing applications", the catalog returned two relevant courses: Building Applications with Force.com - Part 1 & Part 2. So, based on the descriptions I figured the following modules would make a more complete set to start my training:

• Design Considerations. This module introduces the business requirements that an organization might have when setting up security and access.
• Managing Your Users' Experience. Learn how to set up users with appropriate permissions. See how licenses and profiles dictate a user's access to an application.
• Controlling Access to Records. Examine different ways in which users receive access to records: through ownership, organization wide defaults, roles and sharing rules.
• Designing Data Access Security. This module provides a summary of security and access features. Through a number of business scenarios, students will have the opportunity to apply the knowledge that they have gained about determining user access.
• Data Management. Learn the basics of data management including record IDs, external IDs, and object relationships.
• Enhancing the User Interface Using Visualforce. Discover what Visualforce is and its features and capabilities. Learn the basics of Visualforce syntax and how Visualforce components are similar to HTML and XML. Learn how to create Visualforce pages and add them into an application.
• Additional Uses for Visualforce. Continue to explore using Visualforce pages to change the look and feel of a page, to display Salesforce data on a website using AJAX and JavaScript in conjunction with Visualforce, and to develop Visualforce pages for mobile devices.

Personalized Schedule for My 30-Day Action Plan

Yesterday I created The CTA Review Board Candidate's 30-Day Action Plan. But when I looked ahead at my work commitments and personal events, I realized that the plan is useless without the context of my own life. So, I created a daily schedule and used some formulas and conditional formatting to give better form to my plan.

Now that I'm comfortable knowing I won't burn myself out or neglect my personal relationships, I'm ready to dig into Day 1 (at a really late hour, I know).

The CTA Review Board Candidate's 30-Day Action Plan

Having already passed salesforce.com's Certified Technical Architect Multiple-Choice Exam, and having then failed my first attempt at the Review Board Presentation, I'm now faced with a sobering reality: My second (and likely final) attempt at the TA certification is less than 60 days away.

Complicated by the following factors, I asked myself, "Can I really do this?"

• I'm fully billable for 40 hrs/wk between now and then on an important project where my role is the Salesforce technical architect
• I'm the happy father of a 7-month-old, and there's no one at home to support my wife except me, since our closest parent is about 1,000 miles away
• I'm paying out of pocket to take an MBA class right now that I cannot afford to fail

The reality seems to be, "Do I really have a choice?" It's now or never, sink or swim. So, to help center myself and to aid any others who're about to embark on a similar journey, I'm going to lay out what I'm going to do in the next 30 calendar days, dubbing it, The CTA Review Board Candidate's 30-Day Action Plan.

A few notes on terminology used in the plan:

• A "comprehensive scenario" includes use cases for Sales Cloud, Service Cloud, Community Cloud, Chatter, the Salesforce1 Platform, the Salesforce1 mobile app and Heroku
• "Large data volumes" means that at least one object holds over 1 million records
• A "technical work stream" involves making changes to Salesforce itself or to an integration job or migration effort

Luckily for me, in Spring '15 the requirement for a customer case study is no more! This change implies extra scrutiny on the Hypothetical Scenario Exam, Presentation, and Discussion, but I feel the odds for me personally just improved ever so slightly.

All right, then. Let's do this!

Events Created By Apex Respects DST

For my own edification, I wanted to confirm that Apex in Salesforce is capable of automatically adjusting for DST based on the user's local time zone.

The scenario: As a user in the America/New_York time zone, when I create an event using Apex for July 4, 2015 (EDT) at 9:00 AM and another event for December 25, 2015 (EST) at 9:00 AM, I expect the following:

• Both events should appear in the UI as starting at 9:00 AM on my calendar
• The UTC start time for the July 4 event should be 13:00
• The UTC start time for the December 25 event should be 14:00, which accounts for the end of Daylight Savings Time

The following code confirms the expected behavior:

Queueable vs. @future throwdown!

At first blush, the new Queueable interface appears to supersede the old @future annotation in Apex, especially now that in Spring '15 you can chain a job to another job an unlimited number of times. Yes, that's right: unlimited.

So, what's the purpose of @future in this new age of Apex?

Let's start by comparing the well known @future limits with Queuable.

@future consideration	vs. Queueable
Some governor limits are higher, such as SOQL query limits and heap size limits	Some governor limits are higher than for synchronous Apex, such as heap size limits
Methods with the future annotation must be static methods	Queueable implementations must be instantiated as objects before the the execute() instance method is called, leaving room for additional job context
Methods with the future annotation can only return a void type	Queueable classes must implement public void execute(QueueableContext), which is how a job is initiated
The specified parameters must be primitive data types, arrays of primitive data types, or collections of primitive data types. Methods with the future annotation cannot take sObjects or objects as arguments.	A Queueable object can be constructed with any type of parameter, stored as private member variables
Can make a callout to an external service
A future method can’t invoke another future method	You can chain queueable jobs. You can add only one job from an executing job, which means that only one child job can exist for each parent job.
No more than 50 method calls per Apex invocation	You can add up to 50 jobs to the queue with System.enqueueJob in a single transaction
The maximum number of future method invocations per a 24-hour period is 250,000 or the number of user licenses in your organization multiplied by 200, whichever is greater. This is an organization-wide limit and is shared with all asynchronous Apex: Batch Apex, Queueable Apex, scheduled Apex, and future methods. The licenses that count toward this limit are full Salesforce user licenses or Force.com App Subscription user licenses.

From the reverse side, what about known limits with Queuable?

Queueable consideration	vs. @future
The execution of a queued job counts once against the shared limit for asynchronous Apex method executions.
You can add up to 50 jobs to the queue with System.enqueueJob in a single transaction.	No more than 50 method calls per Apex invocation
No limit (except in DE and Trialforce orgs) is enforced on the depth of chained jobs, which means that you can chain one job to another job and repeat this process with each new child job to link it to a new child job.	n/a (cannot chain @future methods)
When chaining jobs, you can add only one job from an executing job with System.enqueueJob, which means that only one child job can exist for each parent queueable job. Starting multiple child jobs from the same queueable job isn’t supported.
You can’t chain queueable jobs in an Apex test. Doing so results in an error. To avoid getting an error, you can check if Apex is running in test context by calling Test.isRunningTest() before chaining jobs.

The verdict: Implement Queueable as a standard approach, and only look to @future if for some reason Queueable gives you unexpected or undocumented problems.

$Action.Contact.AddToCampaign explained

Recently a question came up about using $Action.Contact.AddToCampaign on a Visualforce page. The common usage pattern below for $Action variables does not work as expected.

So, I logged a case with Salesforce to get an explanation for how $Action.Contact.AddToCampaign is supposed to work. And the eventual answer I received after three weeks was very surprising.

In short, the merge variable only works when used as the action value in a form element. Let me illustrate this with the sample Visualforce code below.

The unfortunate answer at this point seems to be that $Action.Contact.AddToCampaign only works if you want to use it inside a custom HTML form, not an apex:form. salesforce.com's recommendation is to use $Action.Campaign.AddCampaign instead, which in my opinion defeats the purpose of easily launching a native wizard to add the contact in a given context to a user-specified campaign.