Designing Applications

Designing Applications for Multiple Users

Design Considerations

• need to know the users or actors of the app
• need to identify
  • data that can be accessed by users
  • data restrictions and revoke access from such sensitive data
  • users who should be allowed to customize the app and assign the necessary permissions

Managing your user’s experience

• Types of licenses
  • every user must have a user license
    • defines the fucntionality permitted for the user and determines the profile available to the user
    • can have only type of user license, but may have many feature licenses
  • Two types of license
    • Salesforce
      • full access to CRM, force.com appexchange apps, standard or custom apps
      • full access to CRM, force.com appexchange apps, standard or custom apps
    • Salesforce Platform
      • custom apps, force.com appexchange apps, no access to CRM functionality, can still use accounts, leads, contacts, reports, dashboards and documents
  • can have add-on features, such as apex mobile user, sf crm content user, marketing user
  • can have more than one type of feature license
• Profiles
  • define user permissions to perform different functions
  • each profile is associated with a license type
  • profile work with sharing models or role hierarchy
• profiles control permissions, access to data and the UI
  • Permissions
    • define all actions that a user in a profile can perform
  • access to data
    • controlled by field level security settings which allow to define object and field level permissions
  • user interface
    • page layouts, tabs, applications available for each user, record types for each profile determine what the users will see when they login
  • two types of profiles
    • standard
      • can’t be created or deleted and permissions cannot be customized
    • custom
      • create or clone the standard profile and modify the settings
  • types of permissions
    • Administrative
      • can grant some administrative permissions to custom profile
    • General User
      • control the ability that standard user can do like editing tasks
    • Standard Object
      • control read, create, edit and delete action on standard objects
    • Custom Object
      • control read, create, edit and delete actions on custom objects
    • View All Data allows administrators to view all records regardless of all other security settings
    • Modify all Data – allows administratos to modify all records
    • Customize Application permits administrators to administer the application
    • API only user cannot login to sf.com. such users can only use the application through API calls
    • Password Never Expires prevents password expiring
  • Permission Sets
    • collection of settings and permissions
    • represent a concept like job title
    • handle the system requirements that previously existed on the profiles
  • user can have only one profile, but can have multiple permission sets
  • while assigning permissiosn to users, use profile to assign most restrictive settings and assign additional permissions using permission sets
  • an org can have upto 1000 permission sets
  • permission sets can be used assign additional permissions, but not to deny permissions
  • permissions can be revoked by
    • removing permission from permission set
    • changing a user’s profile
    • disabling a permission set
  • use permission sets to grant permissions for
    • applications, objects, fields, tabs, apex classes, service provider, visual force pages
  • permissions that are not available in permission sets must be set through profiles (login hours, ip access, etc)
  • revoking delete permission for a child object in master child relationship will not prevent deleting the child record if parent record is deleted
• Field-Level Security
  • restricts access to fields
    • list views, reports, force.com, conenct offline, custom links, mail merge, related lists
  • overrides less restrictive page layout settings
  • set at profile level
  • each profile can have different level of access to object
  • doesn’t allow conditional security of records
  • all users can edit any accessible fields
• Customizing UI and Profiles
  • Record types
    • define the manner in which data is displayed according to business needs
    • determine the page layout and limit the picklist options based on the profile
    • not security tools – do not subclass or partition the data, they work at the UI level and not at the data level
    • users can change the record type of an existing record and it does not affect the values in the record

Controlling access to records

• Record ownership
  • has a owner, sharing based on owner of a record, can be transferred to any user who atleast has read access
  • child records in master detail relationship do not have owner, they inherit from parent record
• Types of owners
  • users – full access if a user is owner. if read permission revoked, then they can’t see their own record
  • queues – allows multiple ownership, assigned manually or thru assignment rules
• Record Access
  • read only access, read-write access, full access
• Ways to obtain record access
  • Full access: owner, above the owner in role hierarchy, contains modify all data permission in profile
  • Read/Write or Read only: owd, role hierarchy, sharing rules, manual sharing, apex sharing, view all data
• Profiles vs Sharing Models
  • profiles
    • control access to objects and fields
    • whether user can view positions
    • which fields the user can view
  • Sharing models
    • control access to records
    • control the positions to view
• OWD
  • security settings that define the base line level of access to records that the user doesn’t own
  • only way to restricts access to data in sharing model
  • 3 level of settings
    • public read-write
    • public read only
    • private
  • Determining OWD
    • identify the most restricted user of this object
    • will there be an instance of object that this user is not allowed to view
    • if yes, then owd is private
    • else,
      • will there be an instance of object that this user is not allowed to edit
      • if yes, then owd is public read only
      • else, then owd is public read-write
  • setting owd for child records in master-detail relationship – child inherits  owd from parents
  • child records in lookup will not inherit owd
  • it is possible to change owd any time, but it may have consequences
  • owd can be set for both standard & custom objects
• Roles
  • control the level of visibility to org data
  • every user associated to role
  • assuming no sharing rules created, users in the same role cannot access each other’s records
• Role Hierarchy
  • defines data access rights granted to users at higher roles
  • users access to all records they own and their sub-ordinates
• record access rolls up with role hierarchy with all standard objects
• with custom objects, a setting named ‘Grant Access using Role Hierarchy’, this can be prevented
• Public Groups
  • Roles are two dimensional structures. Public groups are way of grouping users together to grant them record access.
  • Groups are good way to extend access across the nodes in hierarchy tree
  • ‘All Internal users’ is a default public group. Public groups can be made up of any combination of users, roles and subordinates and other public groups.
  • Can use public groups in a sharing rule to reduce the number of sharing rules
  • Public groups can also be used for folder access.
• Sharing rules
  • are created to grant access to records between users when access does not roll up
  • Using sharing rules, read only and read/write access can be granted to users
  • Sharing rules cannot be more restrictive than owd settings.
• Manual Sharing
  • used to grant access to records on a one-off basis when randon users require record access.
  • Access rights can be granted by the owner of a record, anyone above the owner in the role hierarchy and by the system adminsitrator
  • It is granted at the record level and is not used to grant access at the organization level
• Apex sharing reasons
  • allow developers to define the reason why a user or group of users have access to record
  • apex sharing reasons exist only for custom objects and they are defined for individual objects.
  • each object can have up to 10 apex sharing reasons
  • sharing rule has to be created manually using new manual sharing rules
  • deleting apex sharing reasons will delete all manual sharing rules associated with it
  • Users with ‘Modify all data’ permission can change sharing using apex sharing reasons
  • apex sharing reasons should be used programatically and not through the application

Designing Data Access Security

• Establishing Data Access
  • When you want to determine data access for a object,
    • consider the OWD default
    • the owner of the records
    • uses who need access
    • rules governing data access
  • When determining access to sensitive data, you need to analyze the access requirements and restrictions for each profile