Certified Developer

Since the recorded session of DEV 401 training covers this material in such depth, I am simply going to outline a few notes and relevant links on the study guide.

These notes were written using the Summer 09 Edition.  I passed the exam on 10/28/2009.

Headers are boldEach line of the guide is underlined and may contain links, with my comments immediately following in italics.  Not all points have notes.

 

Salesforce.com Certified Developer Study Guide

Application Design 5%
List and describe components of an application.
List of tabs associated w/App, Default Landing Tab/Page, and Profiles Assigned to App.

Describe the model-view-controller design paradigm.
A very brief breakdown:
Model – Objects/fields
View – VF Pages/CSS
Controller – VF Controller/Apex Code

image_thumb7
image_thumb8
Given a scenario, determine whether sufficient information is available to plan/build/design an
application.

Overview of Force.com Platform 8%
Describe the advantages and disadvantages of building an app on the Force.com platform.

I’m going to outline a few commonly addressed advantages and disadvantages- this is an open ended question so feel free to post a comment.  This is not intended to be a comprehensive list.

  • Advantages
    • Multi-tenant architecture: no hardware or software infrastructure to buy or maintain, almost infinitely scalable.
    • Platform independent.
    • Internet-based access.  A VPN and complex IT network architecture not required, but can be utilized for security purposes (including SSO).  Just plug in, and you’re ready to go.  Salesforce Offline will fill the gaps for short hiatuses away from the internet (e.g. a flight).
    • Appexchange and plenty of other methods to integrate and extend the platform.
    • Speed of deployment; speed of development- both typically much faster than an on-premise solution.
  • Disadvantages:
    • Internet connection required for program access (yes this is both a pro and con).  The cost of internet access in some areas is prohibitively high (rural areas in developing nations for instance) for cloud computing.
    • Can be slower than an on-premise solution.  Since the connection is through the internet, latency and throughput rates are going to be higher than if the server is on the LAN.  This can present a problem for some types of applications (e.g. instant access to high res medical scans).
    • Flexibility – You’ll hear this argument against cloud computing, although I don’t really agree with it.  Each vendor, both cloud and on-premise, have strengths (Appexchange  > ‘flexibility’ and weaknesses (where is my native many-to-many relationship).  The key is to select an appropriate vendor and application for a given a set of needs.
    • Entrusting your data to a 3rd party.  Where do you store your money?  A bank?  The key question to me is ‘Do you trust the company that is housing your data?’.  Salesforce has excellent policies to ensure data privacy and security, and they should- their livelihood depends on maintaining the integrity and privacy of their customers’ data.  Another counter-question I use in the SMB market frequently is ‘How much do you pay your information security staff?’ (I’ve yet to meet an SMB that has a dedicated information security staff person let alone persons).
    • Downtime – GMail goes out for an hour and you hear endless complaining about the ‘woes of cloud computing’.  Counter question: ‘What is your uptime on your Exchange or Notes server?’  (if you accurately measure it, I would be surprised if you’re doing better than Google or Salesforce in uptime).

    Don’t interpret the focus on disadvantages as being negative towards cloud computing.  Quite the opposite- these are some of the counterarguments I’ve used as a proponent of cloud computing (especially Salesforce).  Unfortunately, many of the positive aspects of cloud computing (lack of maintenance, scalability, frequent free updates, etc.) are taken for granted as they are now an expectation of the service.

Describe the types of applications that can be built on the Force.com platform. 
 image_thumb5

List and describe the steps required to design and deploy a successful application built using
the declarative capabilities of the Force.com platform.

1. Plan and Prepare
Build team (executive sponsor, project owner, salesforce administrator, power user)
Define goals and prioritize (define company vision, goals that support this vision, prioritize your requirements) Define your process (Make sure you understand key Salesforce CRM terms, identify key characteristics of your process, review the default Salesforce processes, define and come up with a visual overview of your own process, clarify each step- who is needed and what actions, map process to Salesforce)
Map it to Salesforce (add/rename fields & objects, create workflow & approval, etc)
Decide on what reports are needed
Train the administrator
Notify users when system is live (build anticipating prior to launch, focus on a few aspects that will make reps lives easier, find enthueastic end users, create contests)
2. Set Up Salesforce CRM
(company profile- fiscal years, profiles, org-wide defaults, role hierarchy)
3. Make Salesforce Your Own
4. Ready, Set, Go
5. Make Salesforce CRM a Success

List and describe the building blocks of an application provided by the Force.com platform.
Apps, Objects, Fields, Formulas, Workflow, Approval Processes, Record Types, etc.

List and describe the supported Force.com licenses and editions.

Salesforce CRM License (Editions: Contact Manager – previously Personal, Group, Professional, Enterprise, Unlimited, Developer)
VisualForce is included on all CRM editions (except possibly Contact Manager), Apex is limited to EE,UE,DE.

Force.com Platform License (Free, Enterprise One App, Enterprise Multiple Apps, Unlimited One App, Unlimited Multiple Apps).  Enterprise and Unlimited platform licenses can be added to Enterprise and Unlimited CRM orgs, respectively.  EE and EU licenses are split between One App (user has access to a single application) and Multiple Apps licenses.
All Platform editions include VF and Apex.

Data Model 32%
Describe how to create a functional data model for a business application.

Given a scenario, select the features required to create a function data model for a business application.

Describe the properties and implications of choosing one object relationship type over another and distinguish among relationship types.
Developer training also references a “self” relationship, which is simply a lookup relationship from one object to itself (e.g. Case to case, creating a parent/child case relationship).

Given a scenario, distinguish among object relationship types, describe how to create relationships, and determine which relationship should be recommended.

List and describe the features used to set permission and data access in a custom app.
The app itself does not have any impact on object or field security; it simply lists tabs.  Understand Delegated Data Administration as well; it is not addressed in the above post.

Given a scenario, select the appropriate feature (e.g., profiles, defaults, roles) to provide
appropriate permissions and data access in a custom app.

List and describe optional (Salesforce.com-enabled) features for managing the application
(e.g., create audit fields, encrypted fields, multicurrency).
Encrypted fields (text)
Person Accounts
Territory Management
Multiple Currencies
Customizable Forecasting (requested through the UI)

”Audit Fields” refers to the capability to set the system fields CreateBy, CreatedDate, LastModifiedByID, and LastModifiedDate (by request, through API, usually only for insert).  See “What are Create Audit Fields and how are they used?”.
(If I have missed any please leave a comment!  Thanks!)

User Interface 12%
List and describe the components of any Force.com application user interface (e.g., tabs,
applications, detail pages, list views).

Applications, tabs, list views, page layouts (detail, mini, and console), home page, sidebar, console, etc..  See this post for some additional info.

Given a scenario, determine the capabilities and constraints of the declarative framework for
building a user interface (e.g., what can and cannot be done in a page layout).

Describe use cases for how Visualforce can extend the user interface in the declarative
framework and when to do so.

image_thumb10

Business Logic 23%
List and describe how to create formulas, validation rules, and workflow rules.

Given a scenario, determine which Force.com feature to use to solve a business requirement
and/or describe how to apply the solution.

List and describe the capabilities of the Force.com approval processes.

Given a scenario, select the appropriate features of Force.com approval processes to satisfy business requirements.

List and describe features of the Force.com platform for debugging and monitoring automated business processes.
Monitoring: Outbound Messages, Time-Based Workflow, Case Escalations, API Usage Notifications, Mass Emails, Debug Logs, Scheduled Jobs, Apex Jobs, Email Log Files

Describe use cases for extending business logic through Apex.

Data Management 10%
List and describe the capabilities and constraints of import wizards.

List and describe the capabilities and constraints of API-based tools for managing data.

List and describe the functions of the Force.com Data Loader.

Describe use cases and functions of external IDs and upsert.
An external ID is used for integration with an external system, allowing you to use the external ID instead of the Salesforce ID when performing an upsert using the Data Loader.  This method can be used across different objects as well (e.g. inserting contacts via external ID while matching external ID on the account).  This is covered in the DEV 401 podcast.

Given a scenario, determine appropriate uses of the GUI and command-line interface for the
Data Loader.

Using the Data Loader through the command line is most often used for scheduling jobs.

Describe the characteristics of Force.com record IDs.
Each record ID represents a unique record within an organization.  There are two versions of each record ID: a 15 digit case-sensitive version which is referenced in the UI, and an 18 digit case-insensitive version which is referenced through the API.  The last 3 digits of the 18 digit ID are a checksum of the capitalizations of the first 15 characters; this ID length was created as a workaround to legacy systems which were not compatible with case-sensitive IDs.  The API will accept the 15 digit ID as input but will always return the 18 digit ID.

Reporting and Analytics 10%
List and describe capabilities and constraints of reports and analytics of the Force.com
platform.
Become familiar with each different report type, and each different dashboard type.  Understand how reports feed dashboards.  Understand the capabilities of custom report types as well.

Given a scenario, determine methods for analyzing and displaying data.