Friday 24 May 2013

401 Salesforce Meterial Part - 1

-->


-->
  1. Where in mvc is custom object placed - model

  2. By default what all comes with a custom object Tab?

  3. Functionality "x" is in which edition - unlimited and Enterprise(Answer valid provided x doesn’t change)

  4. How does role hierarchy works in salesforce - Records of jr.exec is visible to his/her seniors

  5. Vlookup with val rule - for a scenario where product name and code mapping is desired.

  6. Database, analytic engine are included in force.com (Other options -dataware house, web browser)

  7. Gauze and table can give you total. Matrix, pie don’t

  8. Consider report n dashboards before designing an application 

  9. Invalid formula field data type - checkbox and email r not there

  10. Which all field cannot be ext id - textarea and formula field - correct answer - Text, Number, Email CAN be Ext Id fields

  11. Production and full sandbox ONLY can have same salesforce id.

  12. With which dev tool can u create custom object - ide, api. Setup is not a tool

  13. Master child relation- child owner is same as master's, child follows same security model, child gets deleted when parent is deleted

  14. Lookups - u can access parent record field value from child record

  15. If a picklist value is "Open" give edit, delete access to SOME users and if it is other than Open do not allow anyone to delete that record - Make that object private in sharing model and create a sharing rule to allow access of that record to a group when picklist value is open

  16. Who can approve a record submitted for approval - Approver and any one above him

  17. Export data every night - commandline data loader
     
  18. Import wizard feature - deduplication

  19. Make change while hovering - Mini page layout

  20. Want to have records in related list filtered on some criteria - filter from related records on a page layout

  21. Multi currency scenario - ISO code is mandatory , roll up summary will be correct

  22. 2 users x,y - access to records based on value of a picklist - To be Answered

  23. If master is deleted - child record would be deleted

  24. Why using formula is better - no test coverage, no IDE requires, do able from browser

  25. Cross obj formula - we can get parent from child and - To be Answered

  26. Junction obj - have 2 masters, manage M:M relationship

  27. Approval process, master detail, lookup, formula field ---study for picklist question like work flows -> correspond to business logic

  28. Best way to test time based workflow - queue, activity history (incorrect - debug log, bug history)

  29. Which properties can be changed from page layout - required, read only
  30. How one can approve a process from mobile- sms, voice, correct - (email, browser)
  31. x->y->z: To make report from related co's , setup>custom report

  32. Web tab, vf tab, custom tab -we can create these types of tab.

  33. With Webservice api -page layout read only is not respected, field level read only is respected

  34. Best option to sum different objects - summary report

  35. Console: The console is a tab that combines a list view and related records into one screen with different frames so users have all the information they need when interacting with Salesforce. With the console, users can quickly find, view, and edit records such as cases, accounts, and contacts with fewer clicks and without switching back and forth between screens. Administrators choose the information displayed in the console to accommodate users’ varied and evolving business needs. Console layouts define what objects are available to users in the console’s list view frame. For example, if you want users to see list views of cases and contacts in the console, then you would add both cases and contacts to a console layout, and then assign that console layout to the appropriate user profiles. A user can only view objects in the console’s list view frame if those objects are added to the console layout to which
their profile is assigned.
  1. System Fields: Salesforce.com has the ability to set system fields through the API. When you are migrating data from an external system, the API lets customers set the CreatedBy, CreatedDate, LastModifiedByID, LastModifiedDate, and a number of other fields on most objects that were previously read-only. By setting these fields, records will appear to have been created at their original created time from your old system. The objects you can edit audit fields are: Account, Contact, Opportunity, Case, Task, Lead, Event, Custom objects.

  2. Encrypted Custom Fields: Encrypted custom fields are text fields that can contain letters, numbers or symbols but are encrypted. The value of encrypted fields is visible to users with “View Encrypted Data” permission.
To enable encrypted fields for your organization, contact salesforce.com.
Encrypted fields are encrypted with 128-bit keys and use the AES (Advanced Encryption Standard) algorithm.
Encrypted custom fields cannot be unique, an external ID, or have default values.
Although other text fields can contain up to 255 characters, encrypted text fields are limited to 175 characters due to the encryption algorithm.
Encrypted fields are not available for use in filters such as list views, reports, roll-up summary fields, and rule filters.
Encrypted fields cannot be used to define report criteria, but they can be included in report results.
Encrypted fields are not searchable, but they can be included in search results.
Encrypted fields are not available in the following: Salesforce CRM Mobile, Force.com Connect for Outlook, Force.com Connect for Lotus Notes, Force.com Connect Offline, lead conversion, workflow rule criteria or formulas, formula fields, outbound messages, default values, and Web-to-Lead and Web-to-Case forms.
You can use encrypted fields in email templates; however, the value is always masked regardless of whether you have the “View Encrypted Data” permission.
If you have created encrypted custom fields, make sure your organization has secure connections using SSL (Secure Sockets Layer) enabled. To enable this setting for your organization, see Setting Session Security.
If you have the “View Encrypted Data” permission and you grant login access to another user, be aware that the other user will be able to see encrypted fields unmasked (in plain text). To avoid this possibility, first clone your profile and remove the “View Encrypted Data” permission from the cloned profile, then assign yourself to the cloned profile before granting login access to the other user. If you do not have the appropriate permissions to clone and change your profile, contact your administrator for assistance.
Only users with the “View Encrypted Data” permission can clone the value of an encrypted field when cloning that record.
Encrypted fields are editable regardless of whether the user has the “View Encrypted Data” permission. Use validation rules, field-level security settings, or page layout settings to prevent users from editing encrypted fields.
You can still validate the values of encrypted fields using validation rules or Apex scripts. Both works regardless of whether the user has the “View Encrypted Data” permission. Data for encrypted fields in the Debug Log is masked. Existing custom fields cannot be converted into encrypted fields nor can encrypted fields be converted into another data type. To encrypt the values of an existing (unencrypted) field, export the data, create an encrypted custom field to store that data, and import that data into the new encrypted field. Mask Type is not an input mask that ensures the data matches the Mask Type. Use validation rules to ensure that the data entered matches the Mask Type selected. Use encrypted custom fields only when government regulations require it because they involve additional processing and have search-related limitations.

  1. Page Layouts:

    1. Page layouts for the user object only include custom fields, custom links, S-controls, and Visualforce pages

    2. Tagging, related lists, custom buttons, and standard field customizations are not included on page layouts for the user object

    3. Field level security is only available only for the custom fields on User object

    4. Field level security is not available for the standard fields on the User object

    5. You can define mini-page layout for the User object but can’t add standard fields or related list

    6. Only Administrator can use the import wizard for Accounts, Contacts, Leads, Solutions and custom objects

    7. Administrator has access to import into any field even if a field is hidden or read only in the page layout or field level security setting

    8. Individual users can import only into the fields that are accessible to them via their page layout or field level security settings

    9. In Personal, Group and Professional editions page layout control which field user can access in related list, list views, reports, connect offline, email and mail merge templates, custom links.

    10. In Enterprise, Unlimited and Developer editions, the access is controlled by field level security

    11. When editing a Person Account page layout, if you add shipping address next the billing address in the Address information section a link will display on the person account edit page that lets you copy the billing address into the shipping address. Also, an equivalent link appear if you add other address to the Address information section

    12. Contact fields and related list are available on the Person Account 
      page layouts. However , contact custom links and custom buttons are not available

    13. Some Items can only be moved to certain sections on the page layout. For example you can drag a custom s-control to any field section on the page layout, but not to a Related list section or Button section

  2. Visual force:

    1. Visualforce uses a tag based markup language to give developers more powerful way to build applications and customize the Salesforce interface. With Visualforce, you can:
      1. Create custom user interfaces that easily leverages standards Salesforce styles
      2. Create custom user interfaces that completely replace the Standard Salesforce Styles
      3. Build wizard and other navigation patterns that uses data specific rules for optimal , efficient application interaction

    2. Visual force is a framework that lets developers to build sophisticated, custom user interfaces that can be hosted natively on the force.com platform

    3. Visualforce framework includes a tag based markup language similar to HTML

    4. In Visualforce markup language, each Visual force component correspond to a course and fine grained user component such as related list, page section or a field

    5. Developer can use Visualforce to create a Visual force page definition. The page definition consist of 2 things:
      1. Visual force markup
      2. Visual force controller

    6. Visual force markup: consists of Visualforce tags, HTML, javascript or any web-enabled code

    7. Visualforce controller: is a set of instructions that specify what happens when a user interacts with the component specified in the associated visual force markup such as when user clicks on a button or links

    8. Controller also provides the data access that should be displayed in a page and can modify component behavior

    9. Standard Controller: consists of the same functionality and logic that is used for a standard Salesforce page. If you use a standard controller, clicking on a Save button in a Visualforce page results in the same behavior as clicking Save on the standard edit page

    10. Custom Controller: is a class written in Apex that implements all of the page logic without leveraging a standard controller

    11. Like other Apex classes, Custom controller also execute entirely in system mode in which the object and field level permissions of the current user are ignored. You can specify whether a user can execute a method in a custom controller based on the user’s profile

    12. Controller Extension: A controller Extension is a class written in Apex that adds to or Overrides behavior in a Standard or custom controller. Extension let you leverage the functionality of another controller while adding your own logic

  3. Standard controller executes in User mode in which the permissions, field level security and sharing rules of the current user are enforced 
     
  4. Because standard controllers execute in user mode—in which the permissions, field-level security, and sharing rules of the current user are enforced—extending a standard controller lets you build a Visualforce page that respects user permissions. Although the extension class executes in system mode, the standard controller executes in user mode. As with custom controllers, you can specify whether a user can execute methods in a controller extension based on the user’s profile. 
     
  5. Custom picklist can be controlling or dependent

  6. Standard picklist can only be the controlling

  7. Standrad picklist can not be dependent

  8. A dependent field works in conjuction with a controlling field to filters its values. The value chosen in the controlling field effects the values available in the dependent field

  9. The field that drives filtering is called as Controlling field. 
     
  10. Standard and Custom checkboxes can be the controlling field

  11. Standard and Custom picklist with at least 1 and less then 300 values can be the controlling field

  12. The field that has its value filtered is called as Dependent field

  13. Custom picklist and multi-select picklists can only be the dependent fields 
     
  14. Universally Required:
    1. Always require a value in this field in order to save a record
    2. Required across all record types
    3. Always display on edit page

  15. Universally Required only works in Custom fields

  16. Universally Required does not work in Standard fields

  17. Unique:

    1. Don’t allow duplicate values
    2. Treat “ABC” and “abc” as duplicate values (case insenstive)
    3. Treat “ABC” and “abc” as different values (case senstive)

  18. Textarea can’t be a unique field

  19. We can set the External ID of a field only for the TEXT, NUMBER and EMAIL data type for the custom fields. Means External ID can only be for custom fields of type TEXT, NUMBER and EMAIL 
     
  20. External IDs is available on all objects which support custom fields

  21. User defined cross-referenced field

  22. Why it is important:
    1. Increases Report and API SOQL performance
    2. Used with Upsert to easily integrate app with other systems

  23. An object can have 3 external ID fields

  24. An external ID contains record IDs from a system outside of Salesforce. You can match against this field during importing or integration, or when using the upsert call. Also, external ID fields are indexed, so selective filters on them should run quickly.

  25. Encrypted Fields: Encrypted fields allows for masking data from all the users except those with “View Encrypted Data” permission. This is provisioned feature and you must contact with Salesforce.com to enable it

  26. Encrypted custom fields can not be Unique fields

  27. Encrypted custom fields can not be External ID fields

  28. Encrypted custom fields can not have default values

  29. Encrypted fields can be modified regardless of whether the user has “View Encrypted Data” permission

  30. How can we prevent user to modify the Encrypted fields:

    1. Use validations rules, field level security setting or page layout setting to prevent the user from editing encrypted fields

  31. Object Relationship:

    1. A relationship is a bi-directional association between two object
    2. Relationship allows us to create links between one objects to other

  32. Force.com platform support the following 4 types of relationship:
    1. Lookup relationship
    2. Master-detail relationship
    3. Many-to-Many relationship
    4. Self


  33. Lookup Relationship:

    1. Creates a loosely typed relationship between two objects
    2. Child row is not automatically deleted when parent row is deleted
    3. No inherited sharing and security. Means the child row does not inherit the sharing and security from the parent record
    4. 25 lookup relationships can be created per object. We can create maximum 25 lookup on a record
    5. Lookup field data on child record is not necessarily required. Means the Lookup field value can be null on child record

  34. Mater-Detail relationship:

    1. Mater-Detail relationship closely links two objects together such that the master record controls certain behavior of the detail record
    2. When a master record is deleted, the detail record is automatically deleted
    3. Owner field on the Detail record is not available
    4. Owner field on the Detail record is set to the owner of the Master record
    5. Owner of the Detail can not be different for Master and Detail record
    6. The security setting for the master record controls the detail record
    7. Same security and sharing setting are applied on Detail as on the Master record
    8. The Master-Detail relationship field (which is the field linking the two objects) is required on the Page Layout of the Detail record
    9. Only 2 Master-Detail relationship are allowed per object

  35. Many-To-Many Relationship:

    1. Allow for the relationship of 2 objects in a Many-To-Many fashion
    2. Implementing a Many-To-Many relationship requires a third junction object

  36. Junction object: When modeling a many to many relationship, you use a junction object to connect the two object

    1. Junction object is a custom object with two master detail relationships
    2. When creating a junction object, consider the following things:
      1. Name the object with a label that indicates it’s purpose
      2. Use the auto number data type

  37. What is a Custom App: A custom application is a logical container for all the objects, tabs, processes and services associated with a business function

    1. A force.com app consist of a name, description, an ordered list of tabs, optionally a custom logo and default lending page
    2. Salesforce.com provides standard apps like Sales, Marketing, Call Center
    3. Custom App display CustomForce logo by default
    4. You can insert your own logo, you need to upload it in to the Document object as a JPG or GIF file. The logo size should be less then 20 KB size
    5. You can set your landing page from the Default Landing tab drop down menu

  38. What is a Custom Tab: 
     
    1. A custom Tab is a user interface component, you create to display custom object data or other web content embedded in the application
    2. There are 3 types of custom tabs:
      1. Custom Object Tab :: display the data of custom object in user interface
      2. Web Tab :: display any external web based application or web page in a user interface
      3. Visualforce Tab::Display any visual force page
    3. Universal Container wants to make sure that user will be able to easily access the new custom objects they have created. They need to create new custom tabs that will quickly guide the people

  39. Page Layouts:

    1. Page Layout defines the organization of
      1. Fields
      2. Custom Links
      3. Visual force pages
      4. Custom s-control
      5. Related Lists on an object detail page or edit page

    2. Page Layout customizations include
      1. Field locations
      2. Page section customizations
      3. Field property: Field property can be “read only, required”

    3. Page layout standard section names can not be modified for standard page layouts

    4. Making a field required on a page layout or through field-level security ensures users must enter a value
    5. If you make a user field universally required, you must specify a default value for that field

    6. Use field-level security as the means to restrict users’ access to fields; then use page layouts primarily to organize detail and edit pages within tabs. This reduces the number of page layouts for you to maintain

    7. Field-level security does not prevent searching on the values in a field. If you do not want users to be able to search and retrieve records that match a value in a field hidden by field-level security, contact salesforce.com Customer Support for assistance with setting up your organization to prevent unwanted access to those field values.

    8. Page layouts can specify whether a given field is required, but the API does not enforce such layout-specific field restrictions or validations in create() and update() calls. It is up to the client application to enforce any such constraints, if applicable

    9. Means if a field is set to required from page layout, the API will not enforce the user to make it as required

    10. Record types can control which picklist values can be chosen in a given record and which page layouts users with different profiles can see. However, such rules that are configured and enforced in the Salesforce user interface are not enforced in the API. For example, the API will not validate whether the value in a picklist field is allowed per any record type restrictions associated with the profile of the logged-in user. Similarly, the API will not prevent a client application from adding data to a particular field simply because that field does not appear in a layout associated with the profile of the logged-in user

    11. When a custom object is created, a Tag object related to it is also created. These object names are of the form: MyObjectName__Tag, similar to AccountTag and other standard object tag objects.

    12. In the Salesforce user interface, you can mark a custom field as required, and this is also enforced in the API. Every custom field has a field isRequired, with a data type boolean. The default value is false. If set to true, every request must supply a value (or leave the current value) to this field. Otherwise, the request will fail. Once the value is set to true, the next time the field is edited or created, the validation will apply, and if there is no value supplied or default value specified, the request will fail.

    13. To edit the isRequired field, you must log in as a user with the "Customize Application" permission
      .
  40. Workflows:

    1. Standardize the internal procedure and automated the business processes

    2. Event based and time-dependent triggering engine

    3. Capabilities of workflow: 
       
      1. Field updates: restricted to updates on source object only
      2. Tasks and alerts
      3. Outbound messaging
      4. Approval Process
      5. More sophisticated workflows may require use of API

    4. Workflow rules are automated processes that trigger criteria based on your business requirements

    5. Workflow have two parts:

      1. Rule criteria: which records should trigger the rule
      2. Workflow actions: what should happen once the rule is triggered

    6. Each workflow rule consist of the following:

      1. Criteria that cause Salesforce to apply the workflow rule.

      2. Immediate actions that execute when a record matches the criteria. For example, Salesforce can automatically send an email that notifies the account team when a new high-value opportunity is created

      3. Time-dependent actions that Salesforce queues when a record matches the criteria, and executes according to time triggers. For example, Salesforce can automatically send an email reminder to the account team if a high-value opportunity is still open ten days before the close date.

    7. Workflow Evaluate Criteria:
      1. When a record is created, or when a record is edited and did not previously meet the rule criteria
      2. Only when a record is created
      3. Every time a record is created or edited

    8. Immediate Workflow Actions:
      1. New Task
      2. New Email Alert
      3. New Field update
      4. New outbound message
      5. Select existing action

    9. You can’t add a time-dependent workflow action for “Every time a record is created or edited” evaluation criteria

    10. For Email Alert action the Recipient type can be the following items:

      1. User
      2. Creater (record creator)
      3. Owner
      4. User
      5. Public groups
      6. Role and subordinates
      7. Roles and internal subordinates etc..

    11. For Email Alert action we can enter 5 email addresses to be notified in the Additional emails

    12. You cannot add time-dependent workflow actions on an active rule. You must de-active that rule and then add the time trigger

  41. Formula Fields: A read-only field that derives its value from a formula expression you define. The formula field is updated when any of the source fields change.

    1. The output type for a formula field can of these types:

      1. Currency (18 decimal places)
      2. Date
      3. Date/Time
      4. Number (18 decimal places)
      5. Percent (18 decimal places)
      6. Text

    2. Formula field help text displays on the detail page

    3. Formula field are not displayed on Edit page and auto calculated

    4. Smart custom fields that can be used to build business specific calculations using simple wizards and excel like formula calculations

    5. Supported on standard and custom objects

    6. Formula fields can reference standard, custom or other formula fields

    7. Formula fields can reference fields on related objects

    8. Cross object formula fields:

      1. Cross objects formula fields enables you to incorporate the merge fields from multiple objects for calculations and display

      2. Create formula that reference fields on parent or grandparent objects up to 5 level

      3. The cross object formula fields can refer the objects up to 5 levels

      4. This enables to display fields from related objects on detail pages

      5. Use a simple wizard to browse across objects and insert fields in formula

    9. Formula fields only display on detail pages

    10. Scenario: the VP of HR at Universal Container is interested in tracking the overall score of each candidate who has been interviewed as well as the number of days a position stays open. What we need to do?

      1. We need to create formula fields to accomplish this task
      2. Create a custom formula field that calculate the overall score from the Review object
      3. Create a new custom formula field that calculates the days opened on the position object

    11. Cross object formula field Scenario: UC wants to make sure that recruiters views Job Applications have important Candidate information at their fingerprints for example the candidate’s email address and phone. In addition they want to have a candidate’s full name and positions they are applying on the offer records

      1. Answer: you can use cross-object formula fields to accomplish that
      2. Create a formula field to pull the Name information from the Candidate object on Job Application object 

    12. There are total 18 data types in Salesforce.com

    13. only 6 data types are supported by formula fields (Number, 
      Currency, Percent, Text, Date, Date&Time)

  42. Roll-up summary fields: A read only formula field that display the sum, maximum or minimum value of a field in a related list or the record count of all the records listed in a related list

    1. Roll-Up summary field is available only for Master-Detail relationship
    2. Roll-Up summary fields are available for all custom relationships
    3. Roll-Up summary fields are available only limited standard relationships like Account-Opportunity
    4. There is an option to include all records in the roll-up or records that meets certain criteria
    5. Scenarios: to help the hire stand out candidates, the HR director of UC wants to see a list of all the combined reviews scores on each job application. You can use a roll-up summary field to calculate this information
      1. Create a roll-up summary field for Total Reviews on the Job Application object
      2. Create a roll-up summary field for Total Review Score on the Job Application object
      3. Create a formula field that calculates the average review score for a job application

  43. Validation Rules: Validation Rules help improve data quality by preventing users from saving incorrect data. You can define one or more validation rules that consist of error condition and corresponding error message. Validation Rules are executed at record save time. If an error condition is met, the save is aborted and an error message is displayed

    1. Uses of Validation Rules:

      1. Make fields conditionally required, depending on the value of another fields
      2. Ensure that number are within a specific range, such as discount is less than 30%
      3. Enforce that the date fields are the correct chronological sequence such as start date is before the end date

    2. Validation rules verify that the data a user enters in a records meets the standards you specify before the user can save the records

    3. A validation rule can contains a formula expressions that evaluates the data in one or more fields and return a value of true or false

    4. The validation rule also include an error message to display to the user when the rule returns the TRUE due to an invalid value

    5. Error message can be displayed directly below field or top of the page

      1. Multiple error messages can be displayed at one time

    6. Record Type Name and ID can be formula merge fields

    7. Standard and Custom user merge fields for the current user are also available 
       
    8. IsChanged(field) function allows validation to be conditional based on whether a specific field value has changed

    9. PriorValue(field) allows access to the previous value of a field

    10. IsNew() allows different validation rules for create vs. update actions

    11. Scenario: UC wants to ensure that reviewer provide an explanation if they give someone a low score for Cultural Fit on the Review object

      1. Answer: Add a validation rule to require that if someone gives a candidate a Cultural Fit score of <2 they must include an explanation

    12. Scenario: UC also want reviewers to always provide specific details if they are recommending someone to hire

      1. Answer: Add a validation rule that require the reviewers to fill the Reason Recommended box if they check Recommended for Hire

    13. Scenario: UC employee should not be able to save a position record if the Hiring Manager field is filled out

      1. Answer: Add a validation rule to require that all positions must have Hiring Manager filled out

  44. Salesforce License Type:

    1. All users must have a license
    2. You may have one than one type of user licenses in salesforce
    3. Different types of licenses allow different level of access
    4. Every profile is tied up with a license type
    5. License Types:
      1. Salesforce Users:
        1. Salesforce
        2. Salesforce Platform
        3. Salesforce Platform Light
        4. Force.com - one App
        5. Force.com – free
      2. Customer Portal Users:
        1. Customer Portal Manager Standard
        2. Customer Portal Manager Custom
      3. Partner Portal Users: Users with a partner user license can only access Salesforce using the Partner Portal.
        1. Bronze Partner
        2. Silver Partner
        3. Gold Partner
      4. Additional license type give access to other applications including: Mobile, Content, Ideas

  45. Profiles:
    1. Profiles defines a user’s permission to perform different functions
    2. Profiles also defines how a user sees records to which s/he has access
    3. Every user has a profile. Single user can assigned to a single profile
    4. There are 6 standard profiles
    5. Permissions on standard profiles can’t be customized
    6. Developer can create custom profiles
    7. When creating a new profile, developer need to select a profile from which to copy over permissions and settings
    8. Each profile is associated with a User License type
    9. Typically organizations will have one profile for each actor
    10. Profiles control Administrative permissions like “Converts Lead”, “Imports personal Contacts”, “Create and Customize Reports”
    11. Few Permissions to Note:
      1. View all data
      2. Modify all data
      3. Customize applications
      4. API only user
      5. Password never expired
      6. API enabled
      7. View set up and configurations
    12. Object permission determines what user can do to the records which they have access
    13. If you donot have Read access for an object, you will not able to Create, Edit or Delete that records
    14. In addition to controlling access to fields, profiles also control access to objects
    15. The profile control whether a user has the ability to read, create, edit and delete each object
    16. Lacking the Read permission for an object means users will not be able to access it all
      1. No access in the application
      2. No access in the reports
      3. No access through search
      4. No access through the API
    17. Administrators can change a user's profile by editing that user's personal information.
    18. A system Administrator can not modify a standard profile permission
    19. There are 4 types of permissions for a Profile:
      1. Administrative Permissions
        1. API enabled
        2. View Set up and configuration
        3. View all data
      2. General User Permission
        1. Convert leads
        2. Import personal contacts
        3. Import leads
        4. Send email
      3. Standard object permissions
        1. Permissions for all standard for Read, Create, Edit, Delete, View All, Modify All
      4. Custom object permissions
        1. Object level permissions on object level
    20. A System Administrator can only modify the custom profile permissions

  1. Field level security:
    1. Restricts user’s access to view and edit fields
    2. Overrides any less-restrictive field access settings in page layouts and search layouts
    3. Field level security controls which fields user can access in related lists, list views, reports, force.com connect offline, mail merge and email templates, importing personal data
    4. Scenario: UC wants to completely lock down edit access to compensation access information from hiring managers through all ways the users access the Recruiting application
      1. Answer: Use field level security to make Min Pay and Max Pay fields on the Positions object to read only for hiring mangers
    5. Scenario: Use field level security to restrict user access the fields. UC wants to make sure that interviewers have sufficient information to conduct interviews, but needs to limit what they see and edit on positions and candidates
      1. Set field level security for Position object: remove the ability for interviewers to see any compensation details
      2. Set field level security for Candidate object: remove the ability to view all the fields except for the candidate’s First Name and Last Name

  2. Record Types: Record Types allow developers to associate different business processes and subsets of picklist values to different users based on their profile

    1. Used to drive which page layout user see when viewing records based on their profile
    2. Benefits of Record Types:
      1. Tailors user interaction experience to specific business needs
      2. Easier Administration
    3. Record Type only affects the way that data is displayed in UI.

  3. Controlling access of Records:

    1. There are number of different settings that influence whether a user can see or edit records:
      1. Users with “View All Data” can see all the records, regardless of other security settings
      2. Users with “Modify All Data” can modify all records, regardless of other security settings
      3. Field level specifies which fields user can see and edit
      4. All of these setting determines to access an object not any specific record
    2. Other settings that determines whether a user can see or edit are part of the sharing model
    3. Sharing model determines which record a user can see and edit
    4. The sharing hierarchy is as following order:
      1. Owner (record owner)
      2. OWD (organization wide default)
      3. Role Hierarchy
      4. Sharing Rules
      5. Manual sharing
    5. Compare Profile and Sharing Model:
      1. Profiles control access to objects like Account, Contact, Lead, Opportunity and Sharing model control access to records like Account record Brocade Communication System etc.
      2. Profile controls access to the fields
    6. So a user’s profile might specify that a user can see the Candidates but the sharing model specifies which candidate that user can see
    7. The sharing model might determines that a user can see Joe Hardle but profiles specifies which fields that user view and edit
    8. Record Owner:
      1. The user who controls or has rights to that particular data record
      2. An owner has the following special previliges:
        1. View and edit capabilities
        2. Transfer capability (record ownership)
        3. Deletion capability
      3. Important Assumption:
        1. Object permissions enabled
      4. Custom objects can be owned by Queues
      5. Every record in salesforce has an owner except:
        1. Child records of master-details relationship, in this case, the owner of the parent record controls both the parent and child

  1. OWD (organization wide defaults): OWD are a security setting that defines the baseline level of access to data records that you do not own
    1. Users to restrict access to data
    2. Defined for the custom as well as several standard objects
    3. Access levels:
      1. Public Read/Write (all user can see and modify every record)
      2. Public Read only (all users can see every record)
      3. Private (user can see every record that they own)
    4. Considerations:
      1. Child records in Master-Detail relationship inherit the OWD from its parent
      2. Child records in lookup relationship have independent organization wide defaults from their parents
      3. Changing organization wide defaults can potentially delete manual sharing if that sharing is no longer needed
      4. Consider your business requirements carefully before setting your OWD

  2. Roles:
    1. controls the level of visibility that user have to an organization’s data
    2. A user may be associated to one role
    3. Role Hierarchy:
      1. Controls data visibility
      2. Controls records roll up for reporting

  3. There are no “Master-details and Lookup type” data type on User object

  4. Rollup summary is not on the user object

  5. Hierarchical Relationship” new data type does exist on the User object only

  6. Apex sharing reasons are used by developers when adding sharing to a record programatically. Using an apex sharing reason prevents standard users from deleting the sharing, and allows the developer to track why they added the sharing.

  7. Standard object is always the master
  8. Standard objects can not be a child

  9. Custom object can not be a master in a standard-custom master detail relationship

  10. Tabular reports are the simplest and fastest way to list your data.

  11. Summary reports list your data with subtotals and other summary information.

  12. Matrix reports list summaries of your data in a grid against both horizontal and vertical criteria.

  13. Debug log categories:

    1. None
    2. Database
    3. Workflow
      1. Assignment rules
      2. Auto response rules
      3. Escalation rules
      4. Approval process
    4. Validation
    5. Callout
    6. Apex code
    7. Apex profile

  14. Apex Code category log levels:

    1. Error, warn, info
    2. Debug
    3. Fine, finer
    4. Finest


  15. Approval process consist of 5 parts:

    1. Process Definition (Global Charac.)
    2. Initial submission (workflow actions)
    3. Step definition (decision criteria, approval assignment)
    4. Final rejection (workflow actions)
    5. Final approval (workflow actions)



No comments:

Post a Comment