Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Data Migration for Remedyforce SaaS Help Desk and High-Speed Digital Service Management


Published on

Today we will be looking at migrating data into Remedyforce- a SaaS help desk solution in the cloud. Remedyforce is built on Salesforce App Cloud for IT Service Management. We will consider The movement of data from an existing IT service management or help desk system (legacy or prior) to a new high-speed IT service management that is built on the Salesforce App Cloud. You can deliver better more thorough digital services if you migrate the right data over.

Published in: Technology
  • Be the first to comment

Data Migration for Remedyforce SaaS Help Desk and High-Speed Digital Service Management

  1. 1. — Sr. Onboarding Consultant August 2015 Hugo R. Gracia Using Remedyforce SaaS Help Desk / Cloud IT Service Management for Record Level Data Segregation
  2. 2. Agenda • Overview • Data Segregation • Remedyforce & Salesforce Concepts • User Types • Profiles & Permission Sets • Role Hierarchy • Sharing Rules • Configuration Steps • Summary
  3. 3. — What is data segregation? 01 Overview and best practices
  4. 4. Data Segregation Overview Data segregation is achieved through the corroboration of various components working together to achieve a tailored solution for each individual company. System Administrator Human Resources Finance General Population IT Staff
  5. 5. Record Level Data Segregation User Types Profiles and Permission Sets Roles and Role Hierarchy Sharing Rules & Org Wide Defaults Components
  6. 6. Administrators Staff Clients User Types
  7. 7. System Administrator Service Desk Staff Service Desk Client Profiles and Permission Sets
  8. 8. System Administrator Human Resources Finance General Population IT Staff Role Hierarchy
  9. 9. Role Hierarchy Best Practice • Keep the number of non-portal roles to 25,000. • Keep the number of portal roles to 100,000. • Keep the role hierarchy to no more than 10 levels of branches in the hierarchy There are a few other things to take into consideration when working with roles: • When a user's role changes, any relevant sharing rules are evaluated to correct access as necessary. • Peers within the same role don't guarantee them access to each other's data. • Modeling the role hierarchy begins with understanding how the organization is structured.
  10. 10. Record Ownership and Queues • Every record must be owned by a single user or a queue. • The owner has full access to the record. • Users higher in a hierarchy inherit the same data access as their subordinates for standard objects.
  11. 11. Record Ownership If a single user owns more than 10,000 records, as a best practice: • The user record of the owner should not hold a role in the role hierarchy. • If the owner's user record must hold a role, the role should be at the top of the hierarchy in its own branch of the role hierarchy.
  12. 12. Sharing Rules and Organization-Wide Defaults Organization-wide sharing settings specify the default level of access users have to each other’s records. You use organization- wide sharing settings to lock down your data to the most restrictive level, and then use the other record-level security and sharing tools to selectively give access to other users.
  13. 13. — 02 Configuration
  14. 14. Configuration of Components • Roles • Role Assignment • Profiles and Permission Sets • Profile Assignment • Permission Set Assignment • Sharing Settings
  15. 15. Role Hierarchy Configuration
  16. 16. Role Hierarchy Creation Manage Users > Roles
  17. 17. Role Hierarchy From this screen you can: • Add Roles • Modify Roles • Assign Roles
  18. 18. Add Role • Under the role that you wish to add another, click on Add Role. • Fill in the information
  19. 19. Populating Role Information Fill in the information for the Role according to the design.
  20. 20. Role The new role has been created and added to the hierarchy. Additional configuration steps might be necessary if this role is to have other roles reporting to it.
  21. 21. Sharing Settings Configuration Navigate to Setup > Administer > Security Controls > Sharing Settings
  22. 22. Incident Object Sharing Settings Incident Object Settings
  23. 23. Sharing Rule Used to either over ride the hierarchy based sharing settings Sharing can be performed across: • Roles • Queues • Public Groups
  24. 24. Sharing Rule Settings As part of the design process, it will have been determined what sharing rules will be necessary if any. If sharing rules are needed, the design will state how the sharing will take place. You use sharing rules only to grant wider access to data, not to restrict access.
  25. 25. Sharing Rule Configuration
  26. 26. Sharing Calculation Upon hitting SAVE on a new sharing rule, a recalculation of access takes place. Depending on the number of records and number of other sharing rules in place, the duration of the calculation will vary.
  27. 27. Sharing Rule List The new rule is now in effect.
  28. 28. — Troubleshooting 03
  29. 29. Troubleshooting What do you do when some one says they can’t see a record they should? • The security layers you have architected will determine where you start. If you know the sharing model well, then you will probably know what component should have provided the access and should start there
  30. 30. Troubleshooting Steps 1. Verify that the user has permissions to access to the object. 2. Identify the user's role who can't see the record and note it. 3. Identify the owner's role of the record and note it. 4. Review the role hierarchy and verify these two roles are in two different branches (they should be).
  31. 31. Troubleshooting Steps 5. Review the sharing rules for the object and make sure there is no rule that will grant the user access. a) This can also cause you to look in public groups as well. Maybe the user just got left out of a group where there is a sharing rule, or does it make sense to create a new sharing rule to grant the user access? This depends on the architecture you are trying to maintain, and applies to both ownership-based sharing rules and criteria-based sharing rules. b) If you are using teams, should this user be on the team for that record? How are teams maintained and how did the miss occur? c) If manual sharing is used, the user may have lost access because the record owner changed. Manual shares are dropped when ownership changes. The manual share could also have been removed using the Share button.
  32. 32. Troubleshooting Steps 6. If you are using territory management, determine if the user missing from one of the territories. Where is the membership of territories maintained and how did the miss occur? Or, maybe the record did not get stamped with the territory where the user is a member. 7/ If you are creating programmatic shares and there are criteria for creating the share in code, review the code to understand why this user was omitted.
  33. 33. — Summary 04
  34. 34. Summary Data segregation can be, and usually is, a complex undertaking. The rule of thumb that is applied here is that 80% is planning and 20% is configuration. Although this document focuses on a non-multi-tenancy organization, the principles apply just the same, with the one exception being that, in a multi- tenancy organization, you will also be dealing with accounts and account hierarchy. Nonetheless, a well-planned out sharing architecture can serve the organization for a long time to come, providing secure record access.
  35. 35. — Bring IT to Life.™ Thank You