Family Support Implementation - System Administration, Configuration and Support Guide
Configuration reference and handover guide for system administrators and support partners
Family Support - Referral Management, Case Management, Outcomes, Financial Gain
This document provides a complete configuration reference and handover guide for the OPFS Family Support Salesforce implementation. It is not a user guide — it is a technical record of decisions, architecture, and operational administration.
Organisational governance and oversight of the platform
Understanding of system design and operational configuration
Day-to-day administration, user management, and configuration
Onboarding reference for incoming Salesforce support providers
Reference for planning enhancements and change management
- Security model and licence configuration
- Data model and object relationships
- Automation inventory
- Reporting and dashboard architecture
- User administration processes
- Key design decisions and known limitations
- Handover reference tables
- End-user operational workflows
- Family Support officer procedures
- Safeguarding and practice guidance
- Salesforce platform training
- Infrastructure and hosting
The OPFS Family Support Salesforce implementation provides a standardised, role-driven platform for recording, managing and reporting on family support activity across all OPFS office locations.
Centralised referral management with internal and external referral routing, status tracking, and allocation workflows
Case records supporting Family Support, Advice & Information and General service delivery, linked to Contacts and all child records
Contact-centred outcome model via Priority Measures and Priority Area Journeys, linked directly to Contact records
Financial Gain custom object linked to Cases, enabling evidencing of financial impact delivered to families
Operational, management and adoption reporting across all Family Support offices and services
Designed to standardise recording whilst supporting local office visibility and management autonomy
The OPFS Family Support implementation is structured around two primary data pathways: referral and service delivery cases. All records relate back to the central Contact, which anchors outcome recording.
Referral Management captures all incoming referrals, routes them to appropriate queues, and triggers Case creation on acceptance
Cases hold the core service record. Contact Logs capture individual interactions and advice provided throughout the case lifecycle
Financial Gain records are linked to Cases and capture monetary outcomes delivered to families for reporting and evidencing impact
Priority Measures and Priority Area Journeys are linked to Contacts — not Cases — reflecting a contact-centred outcome model
The OPFS Salesforce environment contains three application groups. The primary operational application is OPFS Family Support. Additional applications support internal referral access and retained legacy functionality.
Type: Primary Operational Application
Purpose: The main working environment for Family Support Officers, Managers, and Admins. Contains all Referral Management, Case, Contact Log, Financial Gain, and Outcome objects. All day-to-day service delivery recording occurs in this application.
Accessible by: Full Salesforce Licence users
Type: Referral Access Application
Purpose: Provides platform licence users across OPFS with the ability to submit referrals into Family Support without requiring full Salesforce access. Limited scope - referral creation and status visibility only.
Accessible by: Platform Licence users (OPFS Internal Referrals profile)
Type: Retained Existing Applications
Purpose: Existing OPFS Salesforce applications retained in the environment. These were present prior to the Family Support implementation and have not been decommissioned. Administrators should be aware of their presence when managing profiles and page layouts.
Note: Legacy applications represent technical debt. Review decommissioning as part of future platform housekeeping.
OPFS uses a layered security model. Access is controlled from the top down — each layer narrows or extends what a user can see and do. Administrators must understand all layers to manage access correctly.
Two licence types are in use across the OPFS environment. Licence type determines which profiles are available and which objects and features users can access.
Used by: Family Support Officers, Family Support Managers
Provides access to all standard and custom Salesforce objects, flows, reports, dashboards, and the full OPFS Family Support application.
Used by: Internal referral users across OPFS services
Restricted licence. Provides access to custom objects only. Used to enable staff from non-Family Support services to submit referrals without a full licence cost.
The role hierarchy controls upward record visibility. Managers automatically see records owned by users in roles below them. The hierarchy is structured around Head of Service, Managers, and Officers, with location-specific branches for each office.
Public Groups are used as targets for sharing rules, giving office-level visibility across cases. In the OPFS implementation, Public Groups are role-driven — membership is determined by the user's assigned role, not by manual assignment.
Each Public Group includes a Role as a member rather than individual users. This means that when a new user is assigned the correct role, they automatically inherit the appropriate group membership — reducing administration overhead and the risk of missed access.
Queues are used to manage referral and case allocation. Cases and Referral records can be owned by a queue, allowing multiple users to action work without it being assigned to a named individual. Users must be queue members to accept work from a queue.
One queue per office location. Used to hold referrals and cases awaiting allocation to a named officer within that office.
Specialist queues aligned to specific service types. Used where referrals need routing to a specific team or provision rather than a general location queue.
Cases use a Private Organisation-Wide Default (OWD). This means users cannot see any case they do not own or have been explicitly granted access to. Visibility is then extended through a combination of three mechanisms.
Dundee operationally manages the Angus office. To reflect this arrangement in Salesforce, an additional sharing rule has been configured to grant Dundee management-level visibility of Angus cases, beyond what the standard role hierarchy provides.
The OPFS Family Support data model consists of two standard Salesforce objects (Contact and Case) and four custom objects. All objects relate to Contact or Case as parent records, reflecting the dual-centred design of the implementation.
Contact is the primary service user record. It acts as the central anchor for all family and individual data within OPFS Salesforce. All service activity, outcomes, and case records link back to a Contact.
Name, address, phone, email, and preferred communication method
Date of birth, gender, ethnicity, disability, and other equality monitoring fields
Wellbeing and self-assessment fields capturing the service user's own view of their circumstances
Related lists linking to Priority Measures and Priority Area Journeys for outcome recording
The Referral Management object captures all incoming referrals to OPFS Family Support services. It acts as the intake point before a Case is created, and is used by both internal and external referral sources.
All referrals — internal and external — are captured on the same object using the same layout, ensuring consistent data capture across all referral sources
Key fields are tracked for audit and reporting purposes, providing a history of changes to referral status and assignment
Referrals are linked to the Contact (service user) at intake, and to the resulting Case upon acceptance
Referral Management is heavily supported by Screen Flows for allocation. Manual creation outside of flows is possible but not the standard operating process
The Referral Management object uses a defined set of status values to track a referral from intake to resolution. The lifecycle branches depending on the referral outcome and source.
The Referral Management object uses a defined set of status values to track a referral from intake to resolution. The lifecycle branches depending on the referral outcome and source.
The Case object is the central service delivery record. Cases are linked to a Contact (service user) and hold all service interactions, outcomes, and financial records as child objects. Three record types are configured to support different service delivery contexts.
Each record type is linked to a corresponding Lightning Record Page (Lightning App Builder page). Page layouts control field visibility and section structure; Lightning Pages control the component layout — related lists, actions panel, and related components visible on screen.
Private — access controlled entirely through role, group, and sharing rules
Contact Log, Financial Gain — both Master-Detail relationships. Deleting a Case will delete all child records.
Managed via OPFS FS Case Closure flow. Validation rules enforce required fields at closure.
Enabled on key Case fields for audit and reporting purposes
The Contact Log is a custom child object of Case used to record individual interactions with service users. Every appointment, phone call, advice session, or follow-up delivered within a case should be captured as a Contact Log record.
The Financial Gain object captures monetary outcomes achieved for service users as a result of OPFS Family Support intervention. It is a child of Case and is used in impact reporting to evidence the financial value delivered to families.
Outcome recording in OPFS Salesforce is contact-centred, not case-centred. Priority Measures and Priority Area Journeys are child records of Contact — meaning outcomes persist across multiple cases and reflect the person's overall progression, not a single service episode.
Records a specific, measurable outcome for a service user. Captures a baseline score at the start of engagement and a review score at intervals, enabling evidence of change over time.
Captures a service user's journey within a defined priority area — tracking progress, setbacks, and overall direction of travel across their engagement with OPFS.
The following automations are active in the OPFS Family Support implementation. All are implemented as Salesforce Flows. Administrators must review this inventory before making changes to any object, field, or picklist value that may be referenced by these flows.
OPFS Salesforce reporting is structured across three tiers: operational, management, and adoption. Reports are organised into folders with controlled access, and dashboards are built from those reports.
Follow this sequence in full for every new user. Each step is dependent on the previous one. Do not skip steps — incomplete setup will result in broken access and case visibility issues.
When a user transfers between OPFS office locations, their Salesforce access must be updated to reflect their new role. An incomplete office move creates dual visibility or access gaps. Follow this process in full.
- Update user Role to new office (Manager or Officer level)
- Confirm old Public Group membership has been removed
- Confirm new Public Group membership is active
- Remove user from old office location queue
- Remove user from any old service-specific queues if not transferring with role
- Add user to new office location queue
- Add user to relevant service queues at new office
- Log in as user and verify new office case visibility
- Verify user cannot see old office cases (unless manager hierarchy still applies)
- Notify new office manager that access has been updated
Configuration in OPFS Salesforce is interdependent. Changes to one element can have unintended consequences across the security model. Administrators must assess all downstream impacts before making changes to any of the following components.
The following design decisions were made deliberately during the Family Support implementation. Future administrators and support partners should understand the rationale before proposing changes to any of these areas.
Priority Measures and Priority Area Journeys are linked to Contact, not Case. Outcomes persist across multiple service episodes and reflect the person's holistic journey.
All service interactions (Contact Logs, Financial Gains) are held as children of Case, enabling clear case-level reporting and supporting case closure workflows.
Children of service users are recorded as separate Contact records. This allows for reporting across a family unit.
A single layout handles all referral types. Referral source is captured as a field value. Keeps intake consistent and reduces flow complexity.
Case visibility is scoped to office location by default. Officers see cases in their office; managers see their office plus subordinate roles via hierarchy.
Public Groups include Roles as members, not individual users. Reduces manual administration overhead and ensures access follows correct organisational structure automatically.
An additional sharing rule reflects the operational reality that Dundee management oversees the Angus office. This is a deliberate exception to the standard office-boundary model.
The following items represent known limitations, deliberate trade-offs, or areas of technical debt within the current implementation. They are documented to support informed decision-making by future administrators and support partners.
What: Existing OPFS Salesforce applications from prior to the Family Support implementation remain active in the environment.
Risk: Profile and page layout changes may inadvertently affect legacy application visibility. Administrators must be aware of legacy application scope.
Recommended action: Conduct a legacy application decommissioning review as part of future platform housekeeping.
What: A legacy role hierarchy exists from before the Family Support implementation. Legacy roles remain active and hold historical record ownership.
Risk: Legacy roles may appear in role assignment dropdowns, causing incorrect assignments if administrators are unfamiliar with the hierarchy.
Recommended action: Document legacy roles clearly. Consider deactivating legacy roles where no records are still owned by them.
What: Access is managed via a combination of Profiles and Permission Sets rather than a purely Permission Set-based model.
Risk: Inconsistent application of permissions. Changes to profiles may have broader impact than intended.
Recommended action: Future roadmap should consider migration to a Permission Set Group model to reduce profile dependency.
What: Inactive picklist values ("In Triage", "Redirected") remain on the Referral Management Status field to preserve historical record integrity.
Risk: Administrators unfamiliar with this context may attempt to delete these values, corrupting historical records.
Recommended action: Document clearly. Do not delete. Review only if a full data migration is undertaken.
The following areas are likely to require administration attention as OPFS Family Support operations evolve. Each requires an impact assessment before changes are implemented.
Requires: new Role (Manager + Officer), new Public Group, new location queue, new sharing rule, and Dundee/Angus-style rule if operational management overlap exists. Test full security model before go-live.
Requires: queue creation, membership assignment for relevant officers, and verification that allocation flows route correctly to the new queue. Update any picklist values used in flow routing logic.
New fields added to objects must be added to existing report types before they are available in reports. New custom report types may be required for new object relationships. Communicate changes to report owners.
Any change to OWD, sharing rules, profiles, or roles requires a full dependency assessment (see slide 25). Sandbox testing is mandatory. Document all changes with rationale and sign-off.
Before any structural change (objects, fields, flows, security), conduct an impact assessment covering: affected users, affected reports/dashboards, affected automations, and data integrity risk. Use a change control log.
Plan for periodic platform housekeeping: legacy application review, role hierarchy cleanup, migration to Permission Set Groups, and removal of redundant inactive picklist values where safe to do so.
The OPFS Family Support Salesforce implementation is a purpose-built, configuration-driven platform. The key principles that underpin every design decision are summarised below.
Referral → Case → Contact Log / Financial Gain. Outcomes on Contact. Two standard objects, four custom objects.
7-layer model. Case OWD = Private. Role-driven Public Groups. Office-based sharing. Dundee/Angus exception.
Contact-centred outcomes. Case-centred delivery. Single referral intake object. No Record Types on Referral Management.
Three-tier folder structure. Operational, management and adoption dashboards. Reports are the foundation of all dashboards.
8 active Flows covering referral allocation, case closure, outcome entry, rollups, and email management.
The implementation is designed around role-driven access, office-based visibility, contact-centred outcomes and case-centred service delivery. These four principles should guide all future configuration decisions.
The following tables provide a consolidated reference for the key configuration components of the OPFS Family Support implementation.
Service queues exist by location where appropriate for that service:
One Parent Families Scotland — Salesforce Administration & Handover Handbook · Family Support Implementation
-