Case Management & Best Practices 

Cases 101

A case represents an individual’s issue being raised with some aspect of the apprenticeship program and/or factors that impact the ability to carry out apprentice participation (e.g. recent changes in available transportation). 

There are a few ways that cases get created, namely: 

• via manual creation by a staff member through Salesforce

• using the email-to-case feature, where someone emails a support email and a case is automatically created

• a response to a text message “pulse check” indicative of an issue

• or via the Hub 

Once a case is created, it will be addressed by the designated staff member at the affiliate level. Staff will be able to communicate about the case internally through Salesforce, attach supporting documentation, and, in some cases, communicate with the person who submitted the case. 

Cases created internally (by staff) will be assigned to the user who created them unless otherwise specified at the time of creation. This person will be responsible for addressing the issue. 

Cases created externally (i.e. apprentices) will use assignment rules to route those cases to the correct owners, including queues. Each affiliate will have similar criteria based on specific feature use of cases, here is an example of an assignment rule for the Colorado affiliate:

• Status = New

AND

• Case Initiated Via (Origin) = Email - CO

OR

• Case Initiated Via (Origin) = Pulse Check - CO

OR

• Program Affiliate = Colorado

Using the above as an example, a case created with a Status of New and Program Affiliate of Colorado will be assigned to the Colorado Case Queue and all members will be notified there is a new case to look over.

Record Types

There are 2 types of cases in the system: Standard, and Incident MGMT. 

• Standard-type cases should be used for all cases with only one exception: creating an incident report. 

• Incident MGMT cases are created only via manual intervention by CSM, no one else can create these types of cases.  These types of cases are created when some kind of disciplinary action is needed and multiple parties are involved or if severity calls for it, anything like:

  • An apprentice is not behaving in accordance with affiliate guidelines 

  • An apprentice has notified a CSM of inappropriate workplace conduct and is not comfortable approaching a supervisor or employer

  • A supervisor reaches out to a CSM after hearing about potential harm that an apprentice might be subject to 

Each record type will show slightly different fields, and Incident MGMT cases will also have additional resources and links to aid in creating an incident report and associated action plans for individuals. Incident MGMT cases will also have fewer options to choose from when it comes to the fields of Case Reasons and Reason Categories. Below is a list of all categories per Reason:

• Wellbeing

  • Mental Health

  • Physical Health

  • Family/Home Issue

• Accessibility

  • Technology Use

• Schedules

  • School-Related

  • Job-Related

• Transportation

  • School-Related

  • Job-Related

• Performance

  • School-Related

  • Job-Related

  • Attendance & Timeliness

  • Job Training

• Personnel Issue

  • School-Related

  • Job-Related

  • Supervisor

  • Coach

  • School (Counselor)

• Program Engagement

  • Position Eliminated

  • Early Completion

  • Lack of Interest

  • Change of Interest (Pathway/Occupation)

  • Post-Secondary Plans Change

  • Resignation

  • Termination

  • Incident Report

  • Exit Risk

• Resources/Legal

  • Missing Form(s)

  • MOU Non-compliance

• Hub Tech Help

  • Password Reset

  • Profile Video Help

  • Evaluation Help

  • Application Help

  • Daily Report Help

  • Instruction Plan Help

  • Cannot Submit Work

  • Missing Course(s)

• COVID-Specific

  • Infection/Quarantine

  • Layoff

• Other

  • CareerWise Request

  • Training Center Issue/Inquiry

Page Layouts

Regardless of record type, there is a section to the right of the case data where key-related records, actions, and history will be displayed. 

Open

All cases have three subsections here

• Standard Case: 

  • Email Composer 

  • Key Records

  • Feed

• Incident MGMT:

  • Email Composer 

  • Incidents Reports

  • Feed 

You have the ability to open and minimize each section that you want to view to keep the page as neat as possible. Please keep in mind you can only have one sub-section open at a time. For example, if you want to send an email, clicking on the Email Composer tab will close the Key Records tab.

Open

Here is a breakdown of each section:

• Email Composer—This is where emails can be sent to a constituent. You can specify the “From” address, and we recommend using the queue email address. Users can add attachments, insert tables and pictures, and use the component as a full rich text editor.

• Feed—Users can find a running history of activities and field updates on the case. This is also where Case Comments can be created.

• Incident Reports — The related lists for incident management (training materials for this feature is in a separate training doc).

• Key Records — Related records display a few key fields that may be helpful in resolving a case. The sub-sections here are Apprenticeship Details, Account Details (affiliate account), and Case Teams. 

  • The Apprenticeship Details section only appears if the Apprenticeship field is populated.

  • The Account Details section only appears if the Account field is populated.

  • Case Teams is where one-off and ad hoc access to other internal (NOT HUB) users can be added to the case to aid in a resolution. Additional info on this feature can be found here.

Case Creation and Queues

Cases created by an external source (e.g., the Hub or email-to-case) will be assigned to a queue, and CSMs and/or other staff who are members will be alerted to the creation of the new case. 

Queue membership is key for efficient use of the email-to-case and Hub cases features. Queue membership should consist of individuals who can assist or completely resolve submitted issues. When a case is created and assigned to a queue, it is critical that the individual working the case assigns themselves to that case for accurate reporting. 

To take over a case from a queue, a user needs only to:

• Go to Cases, by clicking the tab at the top banner

Open

• Navigate to the queue list view (e.g. “Colorado Affiliate Case Queue)

• Accept the cases on an individual level or multiple at once time

  • Individual level: 

    • Open a case to see the details

    • Click the button “Accept” at the top right of the page

Open

OR

• Multiple at once time: 

  • Click the checkbox next to the case(s) to take over

  • Click the “Accept” button in the top right of the page

Open

List Views

There are Case list views in the system that represent a collection of case records that meet certain criteria. The fields displayed are customizable to each list view but are NOT dynamic on any level. A list of these list views, who will be using them, and the criteria are listed below:

Visibility of Cases

Are you not seeing a case on your related list? It is important to note how case visibility is determined, what are the defaults, and the mechanisms by which certain parts of a case, or the case entirely, are visible to whom. 

Cases, by default, are PRIVATE in the system. This means that ONLY the owner and those higher in the role hierarchy (i.e. directors) can see the case, but certain sharing rules expand that to affiliate members as indicated by the user’s membership in a queue. So what does this mean? Here is an example

For example, let’s say we have 3 roles in a hierarchy: one is a director (A), another is a CSM (B), and another is an Education Partner (C). If users from roles B and C are in the same queue, then each can view cases owned by that shared queue. Once cases are “accepted” (taken over) by an individual user from role B, role C users can no longer see that case unless shared manually (see Case Teams for more info on this). Users in roles B and C report to users in roles A, so A users can see all cases owned by roles A, B, and C. IF this needs to be changed for your affiliate, please submit a ticket here to make that request. 

Open

Case Teams

Who can see cases by default?

Internally only the owner of a case has access to it by default. 

External users can see cases where they are listed as the “Contact” AND the cases in the field “Visible in Self-Service Portal” are checked. For more information on this, check out the Case and Data Security section here. 

How do you add other users to see the case?

When an occasion calls for more than one person’s insight to resolve a case, the owner can add users ad hoc to the case, enabling them to make new comments and update the case without re-assigning the case to an entire queue. These ad hoc users cannot edit existing comments made by other users, and view vs. edit access is determined by the role assigned to the member of the care team that is being added. Case Team members can be either Hub users or other internal users. This allows CSMs to collaborate with supervisors or high school team members to upload docs, create comments, and resolve the issue. 

Every time someone is added to a case they need to be assigned a role. These roles are only editable by internal CW Tech Team members. Each role allows specific access to the case; these are the available roles and access levels you can give users:

Open

Follow these steps to give another user (Hub or otherwise) access to the case, in accordance with the role table above ^:

Open

1. Go to the case you need to share

2. Open the Key Records section and locate the Case Team related list

3. Click the dropdown, select “Add Member”

Open

4. Search for the user that you want to add (NOT Contact)

5. Select the role from the list ^

6. Click Save

Email-to-Case (E2C)

Email-to-case is a feature that enables you to set up a dedicated email address that will create cases in Salesforce for CSMs to work on. Each email address must be set up and maintained by the affiliate, and approximately 1 hour of collaboration time with the CW Tech team to get up and running once the domain is established. 

*It is important to note that ALL emails sent to this email address will create cases in Salesforce, so it is recommended not to re-use an email address or use an existing email address that is currently being used by other team members. 

Emails sent to this address will be assigned to the queue corresponding to the email address. For example, if CW New York has enabled support@cwny.org for this feature and an email is sent by an apprentice to that address, then the case created will be designated as one under the New York affiliate and assigned to the CWNY Case Queue. All members of that queue will also be sent an email with non-PII details and a link to the case in Salesforce. You will need to go into Salesforce and assign the case to yourself with the steps in “case creation and ques”

Cases created by external users (e.g., email-to-case or in the Hub) will run through an automatic contact matching process and will be associated with a Contact record in Salesforce if a match is found. If a match is found and that record is/was an apprentice, the field “Apprentice” will be populated, and additional information will be automatically populated, such as a link to their Account and Relationship and education Manager(s).

Cases in the Hub

In the Hub, users will be able to: submit cases, view cases that have been submitted where they are listed as the Contact (either through the Hub or other means), and even collaborate on resolutions to cases. 

Open

 A tab in the Hub, called “Case Support” has been created where new cases can be submitted and see progress on existing cases related to the user. Currently, students who are not apprentices are the only users who don’t have access to this tab. 

Since users submitting cases in the Hub must log in, we can auto-populate several data points when these cases are created, below is a list of those fields automatically populated:

Can everyone see all of their cases, even internal ones?

The short answer is no. They will only see cases they have submitted and/or the check box “Visible in Self-Service Portal” is checked. For more information go to Case and Data Security. 

Case and Data Security

Cases submitted via the Hub or email-to-case will automatically be visible in the Hub by the person listed as the associated Contact on the case. The Contact field is automatically populated when submitted via the Hub and E2C when the sending email matches a contact that exists in the system. However, not all comments/notes on the case will be visible. That is determined with the checkbox “Public” when creating a case comment. 

Cases created on the backend are not visible to Hub users by default. To enable Hub users visibility to the case, check the “Visible to Portal Users” checkbox on the case. Unlike case comments, the checkbox to display externally does not need to be determined at the start of a case. For example, if a case is created and that checkbox is left unchecked for any reason, you can go back to the case and make it visible in the Hub. This case will then show up in applicable list views for the Hub user. 

When a case goes from internal-only to externally visible, ONLY case comments marked as public will be displayed. Below are screenshots of these visibility checkboxes:

Open

Open

Reporting and Key Fields

There are several calculated fields on the case object, and some need configuration on the Affiliate (Program State) account record to calculate reliably. If these configuration fields are not populated, the default value when used in calculation will be the date the case was last modified + 7. These calculated fields all appear in one section on the Standard Case page layout, “Dates and SLA*.”  

Below is the list of fields, what they calculate, and how the configuration settings mentioned previously:

*SLA == Service Level Agreement, which is the maximum expected amount of time an affiliate has to respond to a submitted/updated case. It does not need to be resolved in that amount of time, only acted upon in that amount of time (excluding weekends). For example, an apprentice submits a case Friday at 3:30 pm and the SLA is 3 days. The owner has until Wednesday at 3:30 pm, to move the case from New to In Progress. In another example, if the case was put into “In Progress” at 9:10 am on a Monday, the same SLA would put the SLA Response Date at 9:10 am Thursday. In this scenario, either an email is owed to the Contact (in which case the Status would be marked as “Waiting on Reply”) or the case would need to be resolved/closed by that date/time.

Below is an example showing: the case status was updated and the next date an update or resolution is expected (orange boxes), the SLA offset in days and the time scale for the “Time in… fields (green boxes), and the cumulative time spent in status “New” thus far (cyan box).

Open

Communication Templates

There are 3 standardized templates used in automation, Auto-Alert (Standard) Case, Auto-Response (Standard) Case, and Case Closed Auto-Send. Each is used at different stages of case resolution and sent to different audiences. Each of these templates is formatted as below and DOES NOT include any PII as part of our data security best practices.

1 - Auto-Alert (Standard) Case

Used to alert the owner of a new case. Cases created and assigned to a queue will result in this email being sent to each member of the queue. Also, cases re-assigned manually to another user will also result in this email being sent to the new user of that case. Below is the template:

“A new case has been created/assigned in Salesforce for you to review! Click the following link to log in to Salesforce and review the case:

Case Number: {{{Case.CaseNumber}}}

Origin: {{{Case.Origin}}}

Subject: {{{Case.Subject}}}

Description: {{{Case.Description}}}

Reason: {{{Case.Reason}}}

{{{Case.Link_to_Case__c}}}”

2 - Auto-Response (Standard) Case 

Used to confirm receipt of email or submission via the hub that a case was created by the user. The user that sent the email or submitted it via the hub would be the person put into the Contact field of the case. When a case is created by a non-apprentice, the Apprentice field won’t be populated initially but you can populate it if the case applies to the apprentice. Whether the Contact or Apprentice field is populated, the system doesn’t care as long as at least ONE of them is populated. There is a validation rule that will prevent any case from being saved if both the Apprentice and Contact fields are left blank. 

Below is the template sent to whoever is listed as the Contact on the case when it’s created:

“We've received your email and a case with the following details has been created. You can either wait for an email response or check for any status updates at the link below:

Case Number: {{{Case.CaseNumber}}}

Origin: {{{Case.Origin}}}

Subject: {{{Case.Subject}}}

Description: {{{Case.Description}}}

{{{Case.Link_to_Case_HUB__c}}}”

3 - Case Closed Auto-Send

Open

Used to send an email to the person listed as the Contact that their case has been closed. Contrary to what the name suggests, this email is only sent when a case is closed using the button “Close Case” and checking the box, Send Close Email.

Below is the template used:

“This is an auto-generated email alerting you that the following case has been closed:

Case Number: {{{Case.CaseNumber}}}

Subject: {{{Case.Subject}}}

Origin: {{{Case.Origin}}}

Reason: {{{Case.Reason}}}

Reason Category: {{{Case.Reason_Category__c}}}

If you feel your issue(s) is not yet resolved, please send an email to {{{Case.Affiliate_Support_Email__c}}} with additional information.”