Same-Org Implementation of IT Service and Service Cloud

Scenarios and challenges

Consolidating two service domains into one Salesforce org presents unique challenges, primarily regarding the protection of sensitive employee data from Service Cloud representatives. Here are the key challenges implementers typically face.

• Overlapping data: Multiple departments use shared objects such as Cases, Accounts, and Incidents, which can lead to data leaks if not properly isolated.
• Administrative overexposure: System administrators typically have access to all data, making it difficult to hide sensitive fields that display employee information such as compensation or wellness data.
• User experience fragmentation: Employees are modeled as person accounts for IT Service implementations, but enabling features such as Person Accounts can clutter the user experience for business-to-business (B2B) Service Cloud representatives in the same org, who don't need to see employee records in their standard views.
• Regulatory compliance: Maintaining General Data Protection Regulation (GDPR) and Health Insurance Portability and Accountability Act (HIPAA) compliance is more complex in a shared environment where employee and customer data coexist.

Shared objects

Review some of the key objects that Service Cloud and IT Service share and that require additional governance. For objects such as Incident, Case, Employee, and Account, we recommend you create separate page layouts, record types, queues, and assignment rules so that the service desk can correctly resolve tickets.

For more information about how Service Cloud uses incidents to manage major service disruptions, see Resolve Interruptions with Customer Service Incident Management.

Admin tasks to address data sharing issues

Move away from open sharing models to a private architecture to secure the environment. Here are a few best practices.

• Establish private data access: Set organization-wide defaults (OWD) for shared objects such as Case, Incident, Account, and Contact to Private to ensure users see only records they own or that are explicitly shared with them. For details on managing these levels, see Set Your Internal Organization-Wide Sharing Defaults.
• Run tests for automations: Transitioning to a Private sharing model requires exhaustive testing of all existing Apex, flows, and work orders to ensure that existing automations don't break because of new record access restrictions. For best practices on testing, see Apex Quick Start.
• Organize user groups: Create distinct public groups for IT users and Service Cloud users to facilitate precise record sharing through criteria-based rules. To learn how to manage these groups, see Create and Edit Public Groups.
• Implement criteria-based sharing: Use record types to control visibility, such as sharing Business Account records with Service Cloud and Employee records with IT Service. For setup instructions, see Create Record Types and Sharing Rule Types.
• Segregate knowledge content: Enable Lightning Knowledge and use Data Categories to ensure IT Service articles aren't visible to Service Cloud AI agents and representatives. For help with categorization, see Add Data Categories to Category Groups. Without proper grounding in Knowledge Data Categories, AI agents can accidentally trigger a Service Cloud flow for an IT Service question. To mitigate this, enable Knowledge Data Categories and configure specific agent data-grounding filters. For instructions, see Ground with Knowledge.
• Configure specialized routing: Set up unique queues and Omni-Channel routing configurations for each department to ensure specialized tickets reach the right representatives. Set up separate case-based routing for B2B representatives and incident-based routing for IT representatives. For details on routing, see Route Work with Omni-Channel and Set Up Omni-Channel Routing for IT Service.
• Restrict data residency: Sensitive employee data in regions such as EMEA can have stricter residency requirements than general customer data. Organizations must evaluate whether strict regional isolation necessitates a separate instance despite the single-org strategy. For details, see Hyperforce Data Residency.
• Use role hierarchy: Optionally, ensure IT managers can see only cases from their direct reportees by enabling Grant Access Using Hierarchies on the Case object. For more information, see Controlling Access Using the Role Hierarchy.

Admin tasks to address user experience challenges

Optimize the service desk representatives' experience through profile-based layouts and filtered views to ensure they remain focused on their specific domain.

Note Requesters must be licensed as Unified Employee License (UEL) users. UEL is the standard Requester license for IT Service Management (ITSM) orgs. Other clouds can license Requesters differently—for example, as Customer Community Plus (CCP) or another license type.

• Filter list views for clarity: Review and update your filtered list views to ensure only records relevant to specific groups are displayed. For example, to prevent B2B representatives from viewing employee person accounts, create filtered list views for Contacts and Accounts with conditions such as Is Person Account = false. For details on setting up these filters, see Edit List View Filters in Lightning Experience.
• Sanitize search results: For each user profile, create search layouts for standard and custom objects such as Case or Account, ensuring the layout shows users what's most relevant to them. Customize search layouts to remove sensitive fields such as annual compensation or personal email from search previews. For instructions on layout customization, see Customize Search Layouts.
• Create record types and page layouts: For shared objects such as Case, Incident, Account, and Contact, create separate record types and associate page layouts to control field visibility for separate user profiles. For more information, see Create Record Types and Assign Page Layouts to Profiles or Record Types.
• Create object-specific quick actions: The UEL profile lacks default access to the Case object. Create a custom permission set with access to the Case object and manually assign it to your employee users. Then, create custom quick actions such as Log IT Incident and Log IT Service Request, and associate them with specific record types for tickets to allow employee users to log different ticket types from the same portal. To learn how to create these actions, see Create Object-Specific Quick Actions.
  

  Note This workaround isn't required for Customer Community Plus (CCP) users who have native Case access.
• Clone the ITSM Portal UEL User permissions: Clone the permission set to create a custom permission set, then manually assign it to your employee users. This gives them complete access to the Employee Services Portal and its capabilities. To learn about the ITSM Portal UEL User permissions, see Create IT Employee Users for the Employee Services Portal.
• Devise specialized custom profiles and public groups: Unified Employee License (UEL) or Platform User License (PUL) users who are requester-only—meaning they use only the Employee Services Portal to submit IT tickets—are indistinguishable from other internal PUL users who have broader platform access. Create specialized custom profiles and public groups to effectively segregate requester-only PUL users from other truly internal or standard PUL users.

Scenarios that work better with strict data isolation

Maintaining separate Salesforce orgs for customer and employee data is recommended when the implementation involves highly sensitive use cases or complex regulatory requirements. Separation is specifically advised in these scenarios.

• Sensitive employee relations and health data: Managing confidential employee records—including disciplinary actions, legal disputes, and medical information such as leave of absence or Family and Medical Leave requests—requires isolation to prevent unauthorized visibility, as administrative access can't be technically restricted at the field level.
• Compensation and career management: Internal processes for payroll, performance reviews, and promotions involve sensitive financial data that should remain logically and physically separate from general customer service operations to ensure privacy and avoid conflicts of interest.
• Regional compliance and data residency: Organizations operating across multiple jurisdictions must often separate employee data to satisfy local privacy laws such as GDPR and specific data-residency mandates that can differ from standard customer-data requirements.

Limitations for same-org implementation

While the single-org strategy is critical for unified operations, certain technical gaps require careful administrative oversight.

• Salesforce system administrators can't be restricted from viewing sensitive employee fields because the standard System Administrator profile includes View All access on all objects and fields. We recommend that you clone the standard profile and modify the access based on your requirements. For instructions, see Clone Profiles.
• While supervisors can manually use Sort and Filter in Omni Supervisor to refine their view, they can't automatically filter dashboards by specific Service Channels, so IT managers or team leaders can see Service Cloud data.
• Employees who are also service representatives require two separate credentials to properly isolate their professional actions from their personal employee records. For guidance on managing multiple logins, see Switch Between Your Salesforce Org and Your Experience Cloud Sites.
• Due to Customer Signals Intelligence (CSI) native filtering capabilities, the system automatically pulls all case types into the dashboard at load time. You can't restrict or prefilter specific case types during the initial load. Clone the preconfigured dashboard to create a new editable asset that filters based on case type. Customizations require a Tableau Next Creator license and the Tableau Next Admin permission set. For more information on configuring dashboards, see Customer Signals Intelligence.
• UEL/PUL users set up as Employees can't be upgraded to a Salesforce (Standard CRM) user license while an Employee record is associated with them. To work around this, create a new user for the fulfiller role with a custom field on the Employee record that references the new user, or remove the Employee record link before upgrading the license. For more information on employee user setup, see Create IT Employee Users for Agentforce Employee Portal.
• There is currently no way to systematically distinguish between IT Case fulfillers and employees submitting IT Service cases (Requesters) when both hold Salesforce (Standard CRM) user licenses. This makes it difficult to apply differential access controls or routing logic based on persona when the license type is identical. To mitigate this, create specialized custom profiles and public groups to segregate requester-only users from standard internal users.

Data isolation and governance validation

After you complete the setup above, use these checks for user acceptance testing (UAT).

• Confirm representatives in one department can't see records owned by another department's queue.
• Confirm record owner changes don't inadvertently expose records across departments.
• Test the role hierarchy to confirm managers see only their reportees' records. Enable or disable Grant Access Using Hierarchies per object as intended.
• Retest existing automations, including Apex, flows, and work orders, after the OWD change to Private.
• Confirm record type selection works correctly when users create records, especially for UEL users who use quick actions.
• Confirm the App Launcher and navigation are limited per profile so that representatives land in the correct console.
• Ask an IT question and a Service Cloud question. Confirm that Agentforce or the chatbot, when grounded to the appropriate Data Category, doesn't surface an article from the other domain.
• Confirm Omni-Channel routes tickets to the correct queue based on record type or entry point.
• Test cross-assignment to confirm rerouting a ticket transfers access to the receiving representative and removes it from the original queue.
• Confirm the System Administrator profile is cloned and scoped so that sensitive employee fields are hidden from unauthorized administrators.
• Review permission sets and confirm that non-admin profiles don't have View All or Modify All on shared objects.
• Evaluate restriction rules for sensitive fields. Restriction rules require Platform Encryption.
• Confirm who can see Setup Audit Trail entries across departments.

IT Service and Service Cloud persona validation

Confirm that each persona sees only the records and capabilities for their domain.

• Persona access:
  • Incident fulfillers can see and edit only IT Incidents, not Service Cloud Incidents.
  • Problem, Change, and Release fulfillers and managers access only IT records.
  • IT desk managers see only Cases and Incidents from their direct reportees through the role hierarchy.
  • IT administrators can't see Service Cloud Cases.
  • Employees see only their reported Incidents, Cases, and Service Requests.
• Employee portal:
  • A UEL user can log an IT Incident from the Employee Services Portal.
  • A UEL user sees only their own submitted tickets on the portal.
  • Custom quick actions, such as Log IT Incident and Log IT Service Request, preselect the correct record type.
  • The CCP user portal experience is tested separately if you use CCP licenses for employees.
• Configuration Management Database (CMDB) and assets:
  • CMDB configuration items are visible only to IT personas, not Service Cloud representatives.
  • Discovery results don't surface in non-IT consoles.
• IT service desk:
  • IT Service Agent actions, including summarization, resolution, and creation from email, work in the shared org.
  • The agent doesn't surface Service Cloud knowledge when resolving IT Incidents.
  • Proactive Assistance, if enabled, is scoped to the IT domain only.
• Slack and Teams:
  • Swarming and incident channels are created correctly for IT Incidents.
  • Employee users can interact with the IT Service agent without seeing Service Cloud content.
  • Employee users have access to standard IT Service capabilities, such as Service Catalog and incident submission.
• Agent workspace:
  • Service Cloud representatives see only customer-typed Cases, not IT Cases.
  • The Service Cloud console doesn't display Person Account records that represent employees.
  • The Customer Account page layout hides IT-specific fields and related lists.
  • Entitlements and Milestones are scoped to Service Cloud contracts only, not IT service plans.
• Incident management validation:
  • If your Service Cloud implementation uses Incidents, confirm that Service Cloud Incidents use a separate record type from IT Incidents.
  • Broadcast alerts are triggered only for Service Cloud Incidents or IT Incidents as intended.
  • Test the Customer Signals Intelligence (CSI) dashboard and confirm it doesn't pull IT case types when the dashboard loads. If it does, document the known limitation and workaround.
• Customer portal:
  • The external customer portal doesn't expose internal employee records or cases.
  • CCP users for customers and CCP users for employees are distinguishable and routed differently.
  • Self-service knowledge surfaces only Service Cloud-domain articles.
• Analytics and reporting:
  • Service Cloud dashboards and reports are filtered to Service Cloud record types only.
  • Report folders are restricted by sharing so that IT reports aren't visible to Service Cloud managers.

Cross-cloud scenarios

These scenarios validate the boundaries between clouds. Test each combination you've implemented.