Posts Tagged ‘SalesForce’
Salesforce Certified Technical Architect
Fall seven times, stand up eight.
– Japanese proverb
Finally, I have this certification. This has been a journey for me, and taken much longer than I anticipated. I did fail the first attempt, but was given a retry (make-up exam) in the sections that I’d failed. I subsequently failed that too. My second, full attempt saw me pass, and in fact I found it quite easy so let me help you learn from my mistakes.
Attempt 1
Late last year I booked in my board review exam. I’m not going to go into the detail of what the board exam entails it’s because this has been discussed in detail here, here and here. I spent a lot of time preparing, and had some ad hoc coaching from the UK SFDC certification team but in the end the hypothetical exam destroyed me. Here’s why:
- I’d been developing apps for nearly a year and was rusty with regards to various features of the platform used heavily in projects e.g. sharing, roles, content, knowledge
- I missed the “formal coaching” that SFDC offers for those that pass the board exam, and thought I wouldn’t need it
Together these two things meant that my approach to the hypothetical, and my real-world experience were weak. I knew I’d failed 2 hours into the 4 hour board. Luckily (I suppose) I did very well in the other areas, and my case study was rock-solid so I was given a “make up” exam (2 months later) in my weakest areas.
Attempt 1.1
At this point I’d been back into consulting and oiled my rusty hinges. I also brushed up on any areas of weakness and felt quite prepared. However, the destruction this time around was even worse, I knew I’d failed in the first hour! The reasons here were:
- I felt the hypothetical here was much more difficult
- I focussed too much on creating the presentation, and too little on understanding the question
- I panicked and solved problems that didn’t exist
Attempt 2
Six months after my original attempt I was back in the swing of consulting, working in every role imaginable from sales through to QA and release management. I’d also gone through the “Seed the Partner” official coaching. I honed my approach to the hypothetical and brushed up on Summer 13. And I passed. And it wasn’t that difficult, here’s why:
- I’d gone through the official coaching with SFDC
- I’d known the theory all along, but also had the opportunity to flex the old consulting muscles
- I convinced myself not to panic
- I read every word of the hypothetical at least twice, focussing on understanding instead of focussing on creating the presentation
- I drew. I’m not very comfortable with Powerpoint as an architecting tool but for some reason felt compelled to use it in my hypothetical previously. This time around I did what I was comfortable with, telling a story backed by several diagrams drawn in front of the judges as I presented.
I’ve also developed several assets that helped me to study and will be sharing them in a series of posts in the coming weeks.
– Wes Nolte, Force.com MVP, Certified SFDC TA, BBQ Master
Salesforce: Sharing Cheat Sheet

Sharing is caring.
Sharing is complex, but necessarily so. It gives you incredibly fine-grained control over data access through it’s flexibility but requires quite a deep understanding to do it properly.
There are great articles out there that describe sharing in detail e.g.
Force.com object and record level security
An Overview of Force.com Security
I don’t want to recreate what’s in those articles, instead I’m providing a short, sharp cheat sheet of the major topics you need to understand. So without further ado…
Sharing Cheat Sheet
Sharing Metadata Records
- “Object[Share]” for standard objects
- “Object[__Share]” for custom objects
- Fields: access level, record ID, user or group ID
- Share records are not created for for OWDs, role hierchies or the “View All” or “Modify All” permissions
Implicit Sharing
- For Accounts, Contacts, Cases and Opportunities only.
- A platform feature, cannot be disabled.
- Access to a parent account—If you have access to a child contact, case or opportunity record of an account, you have implicit Read Only access on that account.
- Access to child entities—If you have access to a parent account, you may have access to the associated contact, case or opportunity child entities. Access is configure per child object when creating a new role.
Organisation-Wide Defaults (OWD)
- All standard objects use sharing access through hierarchies and this cannot be disabled
- Public (Read or R/W) can be seen by all users (including portal)
- Can’t be changed for contacts if person accounts are enabled
No Relationship
- All options are available
Master Detail
- Child objects have their sharing access level and ownership dictated by their parent. This also stands for any grandchildren. The parents value for “Grant access through hierarchies” is also inherited.
- Child objects don’t have a share-record of their own and will be shared along with the master record.
- In fact you cannot even define sharing rules from the object detail-page.
Lookup
- Child objects can have their own sharing access level and ownership. Sharing access through hierarchies can also be disabled.
Manual Sharing
- Removed when owner changes
- Removed when access via OWD becomes at least as permissive as the share
- Private Contacts (those without an Account) cannot be shared manually
Apex Managed Sharing
- Can be used for Manual Sharing although it isn’t called Apex Managed Sharing in this context
- Using Apex to share Standard Objects is always considered Manual Sharing i.e. Apex Managed Sharing is only really a feature for Custom Objects
- Maintained across ownership changes
- Requires “Modify All” permission
Recalculation
- Need to create a class that implements the Database.Batchable interface
- The recalcuation is run when the OWD for the object changes
- The OWD for the object in question must not be the most premissive access level
Choosing the Right Share Type
“Traditional” / Ownership-based Sharing Rules
- You want to share the records that a user, group, queue or role own with another user, group or role (includes portal users with roles).
Criteria-based Sharing Rules
- You want to share records based on values of a specific field or fields with another user, group or role (includes portal users with roles).
Apex Managed Sharing Rules
- Your sharing requirements are batshit cray-cray. Examples include:
- Sharing multiple records at once
- Sharing records on object A based on criteria being met on object B
- Criteria-based sharing using a field not supported by “Criteria-based Sharing”
Manual Sharing Rules
- The record owner, or someone with modify all permission, wants to share an individual record with another user, group or role (includes portal users with roles)
Share Groups
- You want to share records owned by HVP users with internal users, groups or roles (includes portals users with roles)
Sharing Sets
- You want to “share” records with HVP users. These records need to fulfill the following criteria:
- Objects has an organization-wide sharing setting different from Public Read/Write
- Objects is available for Customer Portal
- Custom object has a lookup field to account or contact
Portals
High Volume Portals (Service Cloud Portals)
- Include High Volume Customer Portal and Authenticated Website profiles
- They have no roles and can’t participate in “regular” sharing rules
- You can share their data with internal users through Share Groups
- You can share object records where the object is a child record of the HVP user’s contact or account. This is done with Sharing Sets.
- They can also access records that are:
- Available for portal, and
- (Public R/RW OWD, or
- (Private OWD, and
- They own the record))
- They can access a record if they have access to that record’s parent and the OWD is set to “Controlled by parent”
- Cases cannot be transferred from non-HVP to HVP users
other portals
- Have a role hierarchy at most 3 levels deep and can participate in regular sharing
- Person accounts only have a single role
- Business accounts can have 1 – 3 roles.
Large Data Volumes
- Defer sharing settings (enabled by logging a case) and group calculation on large data loads and modifications
If you’ve got any other items you think should be in this list, let me know in the comments. Peas oat.
Salesforce: Insufficient privileges when trying to access Activity Settings
This strange issue blocked access to certain areas of the setup menu in my production Org, and I couldn’t find a comprehensive solution so here we are.
The problem is documented most comprehensively here with problem statement as:
If you choose to show a custom logo in meeting requests, if the admin who specifies the logo specifies a document that other admins cannot access, then other admins will be locked out of the entire activity settings page.
If the file was created in the last six months you can find out which fart-face did this and have a quick chat with them. However, if the change was made more than 6 months ago you’re in a bit of a sticky situation.
The advice of the aforementioned document is to contact salesforce.com support and ask them to let you know who owns the file. However, you can do this yourself using Workbench.
First log in and then click Workbench > Settings and make sure that “Allows SOQL Parent Relationship Queries” is selected. Then click on Queries > SOQL Query.
SELECT Name, ContentType,Description,folder.name,author.name FROM Document WHERE folderId IN ('USER_ID1', 'USER_ID2', 'etc.')
This query will fetch all the Document records in the relevant users’ private folders. You’re looking for a ContentType that is an image, and hopefully the document name or description will help you further narrow the culprits down. The last step is to email all those people (or get log in access) and get them to check their Documents!
Good luck.
Salesforce JavaScript Remoting: Using Apex and JavaScript objects to pass data from client- to server-side and vice versa
I’ve spoken about how to do this at a high-level during Cloudstock London and there are hints at how it can be done but no formal documentation that I’ve found, so here we are 🙂
Quite simply JavaScript Remoting will transform Apex objects and classes (or collections of these types) into JavaScript objects for you. The opposite is true too but there are some rules you need to observe.
Apex Types to JavaScript Equivalents
This is the easier of the type conversions in that you don’t have to really do anything to make it happen. The code below uses a custom class that I’ve defined but you can do the same with any sObject too. Let’s have a look at the code.
The Controller
public with sharing class RemotingObjectsController { /* The remoting method simply instantiates a two custom types, puts them into a list and then returns them. */ @RemoteAction public static List<CustomClass> getClassInstances(){ List<CustomClass> classes = new List<CustomClass>(); CustomClass me = new CustomClass('Wes'); CustomClass you = new CustomClass('Champ'); classes.add(me); classes.add(you); return classes; } /* My custom type */ public class CustomClass{ public String firstName{get;set;} CustomClass(String firstName){ this.firstName = firstName; } } }
The Visualforce
<apex:page controller="RemotingObjectsController"> <script> // Will hold our converted Apex data structures var classInstances; Visualforce.remoting.Manager.invokeAction( '{!$RemoteAction.RemotingObjectsController.getClassInstances}', function(result, event) { // Put the results into a var for pedantries sake classInstances = result; console.log(classInstances); // Assign the first element of the array to a local var var me = classInstances[0]; // And now we can use the var in the "normal" JS way var myName = me.firstName; console.log(myName); }); </script> </apex:page>
The Output

Console output from the JS code.
JavaScript Types to Apex Equivalents
This is a little tricker, especially when it comes to sObjects. Note that the approach below works for classes and sObjects too.
The Visualforce Page
<apex:page controller="RemotingObjectsController"> <script> /* Define a JavaScript Object that looks like an Account */ /* If you were using custom objects the name must include the "__c" */ function Account(){ /* Note the field names are case-sensitive! */ this.Id = null; /* set a value here if you need to update or delete */ this.Name = null; this.Active__c = null; /* the field names must match the API names */ } var acc1 = new Account(); acc1.Name = 'Tquila'; acc1.Active__c = 'Yes'; var acc2 = new Account(); acc2.Name = 'Apple'; acc2.Active__c = 'Yes'; var accounts = new Array(acc1, acc2); Visualforce.remoting.Manager.invokeAction( '{!$RemoteAction.RemotingObjectsController.insertAccounts}', accounts, function(result, event) { console.log(result); }); </script> </apex:page>
The Controller
There not much to the controller in this case.
public with sharing class RemotingObjectsController { @RemoteAction public static void insertAccounts(List<Account> accounts){ insert accounts; } }
Why is this cool?
Good question. If the Force.com Platform didn’t do this for you then we – the developer – would need to convert ours types explicitly on both the server-side and the client-side, and man-oh-man is that boring, error-prone work. Yet again the guys at salesforce.com have built in a convenience that saves us time and let’s us get on with the work of building cool apps.
Salesforce: JavaScript Remoting – a different way of thinking

Remoting is awesome.
JavaScript Remoting for Apex operates in a very different paradigm from what you might be used to i.e. Visualforce pages have controllers and the two interact through action methods – where this might be a full form submission or some neat AJAX functionality. Remoting also calls controller methods but there is a gaping maw in terms of how the two work under the hood.
I’ve seen a few great articles on the syntax and example usage of JavaScript Remoting for Apex but when I started using it I came across a number domain differences that weren’t documented anywhere. Hopefully my list here will help you in the learning process. The best way to describe the new way of thinking is to examine the features set in contrast to “normal” Apex and Visualforce.
How JavaScript Remoting Differs
- Pass parameters naturally i.e. the call matches the method signature syntactically instead of requiring <apex:param/>.
- Action methods when called in “normal” Visualforce can only return NULL or a PageReference. Remoting allows you to return a wider range of data types, even objects and collections.
- Remoting methods have no access to the view state e.g. if a static variable is initialised to some value (outside the remoting method) a remoting method will see this as NULL unless it is re-initialised in that method! Conversely if a remoting method sets a state variable value the scope of that value is only within that method.
- It’s much faster. I’m building an application at the moment that is 95% backed by JS Remoting and when I show it to other developers they are struck dumb for at least 3 hours because of the speed.
- Neater debugging info in the browser console. Salesforce has done a great job of providing feedback directly to the browser’s console log.
- Each method call gets its own executional/transactional context i.e. fresh governor limits per call!
If I’ve missed anything please let me know and I’ll add it. Viva la knowledge crowdsourcing!
Salesforce: Dynamically determining the field type of a dynamically determined sObject

This solution is quite difficult to find.
Call me crazy but I need to do this from time to time, and every time I do I can’t remember how I did it before! So I then trudge through the API and the Apex docs until I find the answer and that’s no mean feat in this specific case. Well, no more my friends because I’m putting it right here on this very blog!
In short the code below will return (as a String) the type of field that we’re working with. Neither the name of the object or the name of the field need to be known in advance.
public static String getFieldType(String fieldName){ // Assume that "sObjectName" is populated elsewhere Schema.SObjectType t = Schema.getGlobalDescribe().get(sObjectName); Schema.DescribeSObjectResult r = t.getDescribe(); Schema.DescribeFieldResult f = r.fields.getMap().get(fieldName).getDescribe(); if (f.getType() == Schema.DisplayType.String){ return 'String'; } // .... else if return null; }
Salesforce: Different percentage unit test code coverage in different environments

Spot the difference.
Many people are finding that their tests are reporting different degrees of test-coverage in different environments. There are a few things to check if you are getting inconsistent results but there’s a new bug in the wild. Before you assume you have the bug make sure that you’ve:
- ‘Run All Tests’ in each environment. This will tell you a few things viz.
- Perhaps there are tests failing that are bringing coverage in that environment down.
- There are some tests that only fail when run in the browser e.g. MIXED_DML_EXCEPTION will not rear it’s head through the IDE.
- Click the ‘Compile all classes’ link above the Setup > Develop > Apex Classes view. I’m not sure when this lil’ bugger first appeared but it’s darn useful. Essentially it makes sure that all the dependencies in your code are fulfilled e.g. if page A uses controller B that in turn refers to utility class C it’ll make sure each of those pieces exist and work (as far as compilation goes at least).
- Double-check your test classes to make sure they’re not data dependent. If they are and you have different types/amounts of data in your respective environments it’s 100% feasible that the test coverage will be different.
Now if you’ve checked all of the above you might have been afflicted by a new bug which, for some reason, counts braces, whitespace (and more!) as being uncovered by your tests. This is preposterous of course and to fix it simply remove all test history from the deranged environment. Re-running the test and/or deploying them should now be back to normal!
Salesforce: Stop email being sent on user creation or password reset or …
I’ve had to do this a few times but infrequently enough for me to forget how to do it each time. Forgetting things isn’t usually an issue because of our Google Overlords and their mighty The Google but it’s quite a journey down the rabbit hole to find this specific information.
The reasons it’s tricky to find is because the setting that controls whether an email is sent to the user on creation is not directly associated with users but with DML. Long story short you need to set a particular Database.DMLOption e.g.
User u = new User(); // Add some details here ... // Set the DML options Database.DMLOptions dlo = new Database.DMLOptions(); dlo.EmailHeader.triggerUserEmail = false; Database.insert(u,dlo);
Hopefully this information will now be easier to find next time I forget 🙂
Across the Pond with Shannon Hale
@abhinavguptas and I were curious as to the identity of the creator of the SetupScripter, which is now incorporated into the salesforce.com Org setup menu. I dug around a bit and managed to uncover her real identity – community please meet Shannon Hale, Shannon Hale this is the community. She didn’t just stop with that wonderful piece of UX but has moved onto bigger and better things, but I’ll let her tell you about those.
If you’d like to learn more about the genius that is Shannon or just have a chat with her you can get her on twitter at @shannonsans or @bathtubdreamer. You can also check out her online presence at shannonsansserif.com and bathtubdreamer.com.
Onto the Q&A!
Who is Shannon Hale? How did you get into software development and UX design?
I started out as a writer, but in a different field — I wrote and edited for some independent Canadian music and culture magazines. I started technical writing to help pay the bills, and from there wandered through a series of tech positions: technical training, systems analysis and design, and software development. In 2001 I became obsessed with why a product I was coding was difficult to use, and began to independently study interaction design and user experience.
When I’m not being a complete geek — which I am even at home, I always have personal and volunteer web projects going on — I’m sewing, knitting, or binding books. I’m one of those people who always needs to be doing something with their hands.
London Force.com Meetup – 20 October 2011
Yip it’s that time again and boy do we have some very cool speakers this time around. The gig is at Skillsmatter at 6.30pm on 20 October and is summarised in the info below. Please don’t forget to RSVP. Of course there will the be usual beers and pizza 😉
Hope to see you there!
AMJAD KHAN ON FORCE.COM ERD USING SCHEMASPY
Amjad Khan will give a talk to the SafesForce user group on How to Install and run SchemaSpy on any Salesforce Org to generate an ER diagram. More details…
SIMON GOODYEAR ON MAKING BETTER USE OF INTERFACES ON THE FORCE.COM PLATFORM
Simon Goodyear’s talk for the SalesForce user group will give a quick overview on what interfaces are, how you can make better use of them in APEX, and what we gain from doing so. More details…
TESTING ON THE FORCE.COM PLATFORM
Keir Bowden gives a talk for the SalesForce User Group on Testing on the force.com platform, covering TDD, unit testing, continuous integration and test scripting. More details…
EFFECTIVE B2C MANAGEMENT
Stony Grunow gives a talk for the SalesForce User Group on Effective B2C management for companies using the “Contacts and Organisations” package. More details…
TURNING YOUR ORG INTO A FULLY OPERATIONAL BATTLE STATION USING RUBY AND SELENIUM
Bruce Durling will give a talk for the SalesForce User Group on turning your org into a fully operational battle Station using ruby and selenium More details…