Force.com Platform Fundamentals

Iniziamo. È gratuito!
o registrati con il tuo indirizzo email
Force.com Platform Fundamentals da Mind Map: Force.com Platform Fundamentals

1. 6. extending using relationships

1.1. a relationship custom field

1.1.1. a many-to-one relationship on referring and referred

1.1.2. put the relationship field onto the object which is one side on the many-to-one relationship

1.1.3. types

1.1.3.1. lookup relationship field

1.1.3.1.1. simplest

1.1.3.1.2. most flexible

1.1.3.1.3. optional

1.1.3.1.4. how

1.1.3.1.5. impact

1.1.3.1.6. implementation

1.1.3.2. master-detail relationship field

1.1.3.2.1. how

1.1.3.2.2. impact

1.1.3.2.3. when to use

1.1.3.2.4. implementation

1.1.4. examples

1.1.4.1. lookup

1.1.4.1.1. hiring manager relationship from position to user

1.1.4.1.2. job application between position and candidate

1.1.4.2. master-detail

1.1.4.2.1. review on job application

1.2. many-to-many relationship

1.2.1. junction object

1.2.1.1. two master-detail relationships

1.2.1.2. first master-detail relationship will be primary

1.2.1.3. junction object uses color scheme and icon of primary master

1.2.1.4. ownership and sharing rules of junction object is determined by primary master

1.2.1.5. in secondary master-detail relationship, detail objects are deleted as well once the master object is deleted.

1.3. data import

1.4. extra fields

1.4.1. external ID field

1.4.1.1. indexable

1.4.1.2. searchable

1.4.1.3. used for importing data

1.4.2. text field

1.4.2.1. length

1.4.2.2. is required

1.4.2.3. is unique

1.4.2.3.1. is case sensitive

1.4.2.4. is external ID

1.4.2.5. default value

1.4.3. email field

1.4.3.1. is required

1.4.3.2. is unique

1.4.3.3. is external ID

1.4.4. number field

1.4.4.1. length (left of decimal point)

1.4.4.2. decimal place (right of decimal point)

1.4.5. checkbox field

1.4.5.1. default: is checked

1.4.6. phone field

1.4.7. rollup summary field

1.4.8. formula field

1.4.8.1. cross-object formula

1.5. search layout

1.5.1. search results

1.5.2. lookup dialogs

1.5.3. tab

1.5.3.1. related list pay layout is determined by both parent object's related list properties (first) and child object's tab layout setting

1.5.4. search filter fields

2. references

2.1. functions in formula

2.1.1. TODAY()

2.1.2. HYPERLINK()

2.1.3. IFBLANK()

2.1.4. IFNULL()

3. 8. Collaborating with chatter

3.1. setting

3.1.1. enable

3.1.2. email notification

3.1.3. approval posts

3.1.4. coworker inviation

3.1.5. customer inviation

3.2. field tracking

3.2.1. {object : field}

4. 9.Using custom workflow and approval processes

4.1. workflow

4.1.1. workflow rule

4.1.1.1. implementation

4.1.1.1.1. related to an object

4.1.1.1.2. give rule name

4.1.1.1.3. define when evaluating

4.1.1.1.4. define rule criteria

4.1.2. workflow action

4.1.2.1. what we can do?

4.1.2.1.1. task

4.1.2.1.2. field update

4.1.2.1.3. alert

4.1.2.1.4. outbound message

4.1.2.2. when they can be done?

4.1.2.2.1. immediately

4.1.2.2.2. time dependent

4.1.3. associated with a single object

4.2. queue

4.2.1. impelementation

4.2.1.1. queue email

4.2.1.2. supported objects

4.2.1.3. queue members

4.2.1.3.1. by individual users

4.2.1.3.2. by roles

4.2.1.3.3. by roles and subordinates

4.2.1.3.4. by group

4.3. email template

4.3.1. types

4.3.1.1. text

4.3.1.2. html

4.3.1.3. custom

4.3.1.4. visualforce

4.4. approval process

4.4.1. apply approval process to all records or certain records matching criteria

4.4.2. concepts

4.4.2.1. initial submission

4.4.2.2. record locking

4.4.2.3. automatical approval

4.4.2.4. final approval

4.4.2.5. final reject

4.4.2.6. actions associated with iniitial submission, approval / rejection, final approval / rejection.

4.4.2.7. approval step (has)

4.4.2.7.1. approver(s)

4.4.2.7.2. filter criteria

4.4.2.7.3. approval action

4.4.2.7.4. rejection action

4.4.2.7.5. recall action

4.4.2.8. approval action

4.4.2.8.1. not associated with approval step

4.4.2.8.2. action associated with approval step

4.4.2.8.3. same types as workflow action

4.4.2.9. once approval process is activated, approval steps cannot be edited even process deactivated

4.4.3. best practice

4.4.3.1. notify approver through email once submission

4.4.4. implementation

4.4.4.1. target object

4.4.4.2. who can edit once it is locked

4.4.4.2.1. administrator only

4.4.4.2.2. administrator or assigned approver

4.4.4.3. 2 ways to config

4.4.4.3.1. jump star

4.4.4.3.2. standard

4.4.4.4. next automated approver determined by manager

4.4.4.4.1. record owner's manager

4.4.4.4.2. record submitter's manager

4.4.4.5. approver page layout

4.4.4.5.1. only can be configured / provided in approval process configuration process

4.4.4.5.2. fields displayed on the page layout

4.4.4.6. security setting

4.4.4.6.1. from where approver can access approval page?

4.4.4.7. who can submit

4.4.4.8. adding approval history related list to the target object all pay layout

4.4.4.9. allow submitter to recall

4.4.4.10. approval steps

4.4.4.10.1. step number

4.4.4.10.2. step name

4.4.4.10.3. step record filter criteria

4.4.4.10.4. select approver

4.4.4.10.5. allow approver's delegate to handle

4.4.5. process visualizer

5. 10. Analyzing data with reports and dashboards

5.1. the need of company managers and executive staff

5.2. report

5.2.1. is composed of

5.2.1.1. table of data

5.2.1.1.1. columns

5.2.1.1.2. records

5.2.1.2. records filter

5.2.1.3. one or multiple grouping

5.2.1.4. graph

5.2.2. 3 formats

5.2.2.1. tabular

5.2.2.1.1. simplest

5.2.2.1.2. no grouping

5.2.2.1.3. no graph

5.2.2.2. summary

5.2.2.2.1. grouping row of data

5.2.2.2.2. subtotal view

5.2.2.2.3. charts

5.2.2.2.4. when used

5.2.2.3. matrix

5.2.2.3.1. grouped by both row and column

5.2.2.3.2. graphs

5.2.2.3.3. when used

5.3. report tab

5.4. report folder

5.5. dashboard

5.5.1. show data from source reports as visual components

5.5.2. every dashboard has a running user

5.5.2.1. which data is displayed in the dashboard

5.5.2.2. access to the details depend on viewer's security setting

5.5.3. dynamic dashboard

5.5.4. 5 varieties

5.5.4.1. charts

5.5.4.1.1. bar

5.5.4.1.2. column

5.5.4.1.3. line

5.5.4.1.4. pie

5.5.4.1.5. donut

5.5.4.1.6. funnel

5.5.4.2. tables

5.5.4.3. metrics

5.5.4.4. gauges

5.5.4.5. visualforce pages

5.5.5. schedule a dashboard freshing

5.6. custom report type

5.6.1. primary object

5.6.2. related objects

5.6.3. relationship between primary and related

5.6.4. page layout

5.7. create a report

5.7.1. select a report type

5.7.2. select report format

5.7.3. define filters

5.7.3.1. standard filters

5.7.3.1.1. by owner

5.7.3.1.2. by date

5.7.3.2. custom filters

5.7.3.2.1. field filter

5.7.4. adding charts

5.7.5. varies

5.7.5.1. create a summary report

5.7.5.1.1. select grouping field(s)

6. 11. Moving beyond point-and-click app development

6.1. mash-up

6.1.1. web service

6.1.2. visualforce

6.2. visualforce pages

6.2.1. controller

6.2.1.1. the style of the page

6.3. mass update

6.4. custom buttons

6.4.1. detail page button

6.4.2. list button

6.5. sites

6.5.1. public access setting

7. 7. Security and sharing data

7.1. page layout setting

7.1.1. {object : page layout}

7.1.2. standard and custom objects

7.2. data administration

7.2.1. global data administration

7.2.1.1. View All Data

7.2.1.2. Modify All Data

7.2.2. app / object data administration

7.2.2.1. View All (on object level)

7.2.2.2. Modify All (on object level)

7.3. concepts

7.3.1. static

7.3.1.1. 3 levels of access

7.3.1.1.1. object level

7.3.1.1.2. field level

7.3.1.1.3. record level

7.3.1.2. profile

7.3.1.2.1. the following can be set through profile

7.3.1.2.2. define profiles as per job function

7.3.1.2.3. 6 standard profiles

7.3.1.2.4. app setting

7.3.1.2.5. tab setting

7.3.1.2.6. user/function permissions

7.3.1.3. field securities

7.3.1.3.1. 2 ways to define

7.3.1.4. record permission

7.3.1.4.1. level 1 - org-wide defaults, most restricted definition

7.3.1.4.2. level 2 - role hierarchy

7.3.1.4.3. level 3 - sharing rules

7.3.1.4.4. level 4 - manual sharing

7.3.1.5. record type

7.3.1.5.1. show ... to different users based on profiles

7.3.2. dynamic

7.3.2.1. create a user-object access matrix

7.4. best practices

7.4.1. create new profiles from standard profiles, then edit

7.4.2. whether role hierarchy is used to grant access can be defined / changed / set on each object

7.4.3. cannot define sharing rules on the detail object in master-detail relationship

7.4.4. sharing access to a junction object record is determined by

7.4.4.1. sharing access to both associated master records

7.4.4.2. Sharing Setting option on the relationship field

7.5. how-to-do

7.5.1. 1. create profile (thru cloning)

7.5.2. 2. set app access thru profile

7.5.2.1. {custom app : is visible}

7.5.2.2. which custom app is default

7.5.3. 3. set tab access thru profile

7.5.3.1. options

7.5.3.1.1. default on

7.5.3.1.2. default off

7.5.3.1.3. tag hidden

7.5.4. 4. set object security thru profile

7.5.4.1. {object : is able to C / R / U / D, is able to view / modify all}

7.5.4.1.1. view all - be able to ready all records

7.5.4.1.2. modify all - full access to all records

7.5.5. 5. set field-level security thru profile

7.5.5.1. {object : field security setting}

7.5.5.1.1. {field : is visible, is read-only}

7.5.6. 6. set org-wide defaults for record level security

7.5.7. 7. set role hierarchy

7.5.7.1. create a role

7.5.7.2. assign users to that role

7.5.8. 8. set sharing rules

7.5.9. 9. manually share records

7.5.10. 10. set record types

7.5.10.1. select an object

7.5.10.2. create a record type

7.5.10.3. profile setting

7.5.10.4. picklist value setting

7.5.10.5. define different page layouts for different record types and assign them to different profiles

7.5.11. 11. delegating data administration

7.5.11.1. 2 ways to do

7.5.11.1.1. object-level permission

7.5.11.1.2. delegated administration group

7.5.12. function permissions

7.5.12.1. administrative permissions

7.5.12.2. general user permissions

7.5.12.3. {function : is checked / enabled}

8. author: Hans Pan

8.1. updated on 7/23/2012

9. 1. introduction

9.1. the technologies behind

9.1.1. multitenant architecture

9.1.1.1. `latest patches and functionalities

9.1.1.2. no worry on update / upgrade

9.1.2. metadata-driven development model

9.1.2.1. metadata in DB

9.1.2.2. not hard coded

9.1.2.3. higher productivity

9.1.3. web service API

9.1.4. Apex

9.1.5. Visualforce

9.1.6. salesforce mobile

9.1.7. sites

9.1.7.1. share apps installed on salesforce to users out of salesforce

9.1.7.2. no username and password needed

10. 2. about recruiting app

10.1. technologies offered by platform

10.1.1. custom objects

10.1.2. security and sharing rules

10.1.3. workflow and approval process

10.1.4. custom reports and dashboards

10.1.5. visualforce

11. 3. reviewing database concept

11.1. an object in force.com is more than a table

11.1.1. built-in user interface

11.1.2. security and sharing model applied

11.1.3. workflow and approval process activated and supported directly

11.1.4. reports supported directly

11.2. terms

11.2.1. object

11.2.1.1. standard object

11.2.1.2. custom object

11.2.2. field

11.2.2.1. standard field

11.2.2.2. custom field

11.2.3. data value

12. 4. building a simple app

12.1. an app

12.1.1. name

12.1.2. logo

12.1.3. set of tabs

12.1.4. default landing tab

12.1.5. profile assignments

12.1.5.1. {profile : is visible, is default}

12.2. in iterative way

12.3. an object

12.3.1. name

12.3.1.1. lable name

12.3.1.2. object name

12.3.2. record name field

12.3.2.1. data type

12.3.3. optional features

12.3.3.1. allow reports

12.3.3.2. allow activities

12.3.3.3. track field history

12.3.4. deployment status

12.4. a tab

12.4.1. for an object

12.4.2. color scheme and icon

12.4.3. profile assignments

12.4.3.1. {profile : option}

12.4.3.1.1. default on

12.4.3.1.2. default off

12.4.3.1.3. tab hidden

12.4.4. app assignments

12.4.4.1. {app : is accessible

12.5. a field

12.5.1. data type

12.5.1.1. text type

12.5.1.1.1. text

12.5.1.1.2. text (encrypted)

12.5.1.1.3. text area

12.5.1.1.4. text area (long)

12.5.1.1.5. text area (rich)

12.5.1.2. currency type

12.5.1.3. checkbox type

12.5.1.4. date type

12.5.1.4.1. build-in popup calendar dialog

12.5.2. field lable name

12.5.3. field name

12.5.4. field security setting on various profiles

12.5.4.1. {profile : is visible, is readonly}

12.5.5. layout field setting

13. 5. enhancing with advanced fields

13.1. advanced fields

13.1.1. picklist type

13.1.1.1. standard picklist

13.1.1.2. multi-select picklist

13.1.2. field dependency

13.1.2.1. controlling field

13.1.2.2. dependent field

13.1.3. custom formula field

13.1.4. dynamic default field value

13.2. validation rules

13.2.1. rule name

13.2.2. error condition

13.2.3. error message

13.2.4. where to display error message

13.3. page layout

13.3.1. section

13.3.1.1. section name

13.3.1.2. layout

13.3.1.2.1. one column

13.3.1.2.2. two columns

13.3.1.3. tab-key order

13.3.1.4. display section header on

13.3.2. field properties

13.3.2.1. required field

13.3.2.2. readonly field