02._EXHIBIT_B-_FUNCTIONAL_AND_NON-FUNCTIONAL_REQUIREMENTS.xlsx
XLSX spreadsheet 157 KB Posted
- Attached to
- EDD RFP 3475 for Salesforce M&O
- Solicitation number
- 0000039456
- Issued by
- California
About this file
This is a Functional and Non-Functional Requirements document for the Employment Development Department (EDD) of California in support of RFP 3475 for Salesforce Maintenance & Operations Support. The document outlines comprehensive technical and operational requirements for Salesforce system support services, including system administration, platform maintenance, configuration management, user support, and performance optimization. The requirements encompass functionality across multiple Salesforce modules and cloud services, with detailed specifications for system availability, data management, security protocols, and integration capabilities. The document establishes baseline service level expectations and technical standards that bidders must meet to support EDD's ongoing Salesforce environment management and operational needs.
The requirements document specifies both functional capabilities—such as user administration, customization support, reporting and analytics, and system upgrades—and non-functional requirements including system performance benchmarks, security standards, disaster recovery procedures, compliance with California state regulations, and documentation and training support. The document serves as the technical foundation for evaluating bidder qualifications and proposed solutions, ensuring that selected vendors can deliver comprehensive maintenance and operations support that meets EDD's critical business requirements for Salesforce platform administration and user support services.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 04._EXHIBIT_C-_COST_WORKBOOK.xlsx | XLSX spreadsheet | |
| 05._EXHIBIT_I-_SF_INTERFACES.xlsx | XLSX spreadsheet | |
| 01._EDD_RFP_3475_for_Salesforce_M_O.pdf | ||
| 03._EXHIBIT_B1-_BACKLOG.xlsx | XLSX spreadsheet |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
myEDD Requirement ID Requirement Bidder Agrees to Meet?
Yes/No.
| myEDD-1 | The system will support mandatory MFA enrollment as a factor via email. |
| myEDD-2 | The system will enable the user to select MFA recovery questions. |
| myEDD-3 | The system will support up to one (1) optional MFA enrollment factor of SMS or Voice. |
| myEDD-4 | The system will not support international numbers for SMS or for Voice. |
| myEDD-5 | The system will challenge the user with a configured factor when user access the system. |
| myEDD-6 | The system will prompt the user to reset their password when user accessed the system with an expired password. |
| myEDD-7 | The system will enable authenticated users to access UIO, SDIO, and BOS line of business applications. |
| myEDD-8 | The system will enable users to manage their account to set language, preference, email address, password, recovery question, and factor enrollment. |
| myEDD-9 | The system will enable password reset from Admin Utility. |
| myEDD-10 | The system will log out inactive users after 30 minutes. |
| myEDD-11 | The system sessions (without a user logged in) will expire after 30 minutes. |
| myEDD-12 | The system will start the password recovery process when the user enters an email for a known account. |
| myEDD-13 | The system will challenge the user with their recovery question and data elements pertaining to their account. |
| myEDD-14 | The system will reset the user password on successful challenge answers. |
| myEDD-15 | The system must have system wide messaging to alert users to system maintenance or alerts. |
| myEDD-16 | The Salesforce system should cache the following values from Okta daily: Group, Password policy. |
| myEDD-17 | The system login screen should present the user with email and password fields to allow them to log in. |
| myEDD-18 | The system login screen should present the user with an option to reset their password. |
| myEDD-19 | The system login screen should present the user with an option to register, which links to registration screen. |
| myEDD-20 | The system should ensure the provided email address (including permutations) is not already used in Salesforce or Okta before allowing the user to register. |
| myEDD-21 | The system will provision the user in Okta after the user has provided valid registration attributes. |
| myEDD-22 | The system will verify registration via email to the email address registered. |
| myEDD-23 | The system will not honor email registration verification after 48 hours. |
| myEDD-24 | The system must support text for the 8 most commonly used languages: English, Spanish, traditional Chinese, simplified Chinese, Vietnamese, Tagalog, Korean, and Armenian. |
| myEDD-25 | Users who have an unverified identity should be prompted to verify their identity when they attempt to file a new claim as a claimant in Line of Business Web Application. A user’s identity is considered unverified if they have never completed identity verification or their previous identity verification has expired. |
| myEDD-26 | Claimant users who are assigned to verify their identity with ID.me by the system’s bifurcation logic should be redirected to ID.me to complete identity verification. |
| myEDD-27 | Claimant users who are assigned to verify their identity with Socure by the system’s bifurcation logic should be redirected to myEDD to complete identity verification. |
| myEDD-28 | Users should have three weeks to complete the passive identity verification process. |
| myEDD-29 | Users who do not complete the identity verification process within three weeks should be forced to restart the process. |
| myEDD-30 | Users who restart the identity verification process should be sent to the same identity verification system that they were originally put through unless the bifurcation logic is configured to only send users to a single identity verification system. |
| myEDD-31 | Users should begin identity verification with a passive verification of their personal information. |
-Unverified users who navigate to the myEDD dashboard before completing passive verification should see a card at the top of the dashboard informing them that they need to complete the identity verification process. This card should have a link that navigates the user to the passive verification flow.
myEDD-32 The following attribute should be collected during passive verification:
First Name Last Name Date of Birth
SSN
Phone number Address
| myEDD-33 | Before submitting their information for verification, users should be given the opportunity to review their entries on a summary page. |
| myEDD-34 | If the user wants to change any of their entries on the summary page, they should be taken directly to the screen that has the field they want to change. |
| myEDD-35 | If a user navigates to a screen where they previously entered information, the fields should auto populate with the data they entered. |
| myEDD-36 | Users should not be able to view or edit the personal information they entered as part of the passive identity verification in myEDD once they submit it. |
- Users will be able to update their phone number as part of the existing MFA options in the My Profile sections.
| myEDD-37 | After the user confirms and submits their information, the system should send the data to Socure. |
| myEDD-38 | Socure should evaluate the information provided by the user and return one of the following responses: |
- Accept
- Refer
- Review myEDD-39 If Socure returns an Accept response, the system should redirect the user to an Accept screen.
- The accept screen should have a link to the LOB application that the user came from.
myEDD-40 Socure should return a Review response in the following scenarios:
- Risk score is greater than or equal to 0.98
- Email risk score is greater than or equal to .995
- Phone risk score is greater than or equal to .995
- R913 - SSN/ is invalid
- R901 - SSN/ cannot be resolved to the individual
- The identity may not be the primary device user (I403) AND the phone subscriber has been correlated with the input phone number for between 0 and 30 days (R631) AND the phone number has been in service for less than 30 days (R622)
- The email address has not been seen before (R566) OR Email is first seen under 30 days (R582) AND the risk score is greater than or equal to .96
- R704 -Address is a correctional facility myEDD-41 Users who enrolled in SMS or Voice Call for their MFA method should have their phone number used for identity verification.
- These users should be able to change the phone number being used.
- Users who change their phone number during the identity verification process should have their old phone number unenrolled from MFA.
| myEDD-42 | Users who did not enroll in text or voice for their MFA method should be given the option to provide a phone number for Identity Proofing. |
| myEDD-43 | Users who provide a phone number for Identity Verification but didn’t provide one for MFA should be given the option to enroll in SMS or Voice Call MFA. |
| myEDD-44 | Users who change their enrollment method will receive the existing “Factor-change-enroll" email.” |
| myEDD-45 | Only US phone numbers should be allowed. |
| myEDD-46 | The field should mask incrementally, masking all characters entered before the current character. If the user’s focus leaves the field all characters should be masked. |
| myEDD-47 | The field should have a show/hide toggle. |
| myEDD-48 | The field should not mask hyphens. |
| myEDD-49 | Users should be required to provide a single address. |
| myEDD-50 | The system should accept PO boxes, group homes, and non-residential addresses. |
| myEDD-51 | The system should utilize Pitney Bowes to normalize the address provided by the user. |
| myEDD-52 | The system should only attempt to normalize US addresses. |
| myEDD-53 | Users should be given the option to use a standardized version of their address provided by Pitney Bowes. |
- If no standardized version exists for the address provided or if the user-entered address exactly matches the standardized version, the user should not be prompted to use a standardized version provided by Pitney Bowes.
| myEDD-54 | The system should store both the user-entered address and the standardized address and associate them to the user record. |
| myEDD-55 | The date of birth fields should have field-level validations that check if the user is a minor based off of the birthdate entered. |
| myEDD-56 | The system should prevent users who are identified as minors from verifying their identity. |
| myEDD-57 | The system should not submit any information provided by users who are identified as minors. |
| myEDD-58 | The system should capture the identity verification information entered by the user. |
| myEDD-59 | The system should distinguish between user-entered data that has not been proofed by Socure and user-entered data that has been proofed by Socure. |
| myEDD-60 | The system should provide reports on the following data points: |
- Daily counts of accepted and failed users
- Counts of top reason codes for rejection
- Counts of abandoned within Socure Passive verification
| myEDD-61 | Salesforce should track the user’s progress through the entire Socure life cycle. |
| myEDD-62 | Users who navigate away from the flow during passive verification should be able to return at any point so long as they haven’t submitted the data to Socure. |
- Users who return to the passive verification flow should be directed to the last screen they reached before they navigated away from the process. Any data they had previously entered should be pre-populated.
| myEDD-63 | Users who bookmark any of the identity verification screens and have not completed their identity verification process should be forced to authenticate before being directed to their bookmarked page. |
| myEDD-64 | Users who bookmark any of the identity verification screens and have already completed their identity verification should be forced to authenticate and then redirected to the myEDD dashboard. |
| myEDD-65 | EDD staff and contractors should be able to access the Socure backend dashboard through EDD App Store. |
| myEDD-66 | Socure should use an exact match when evaluating the Date of Birth value during passive verification. |
| myEDD-67 | Socure should use an exact match when evaluating the SSN value during passive verification. |
| myEDD-68 | The system should identify and log when users abandon the identity verification process. |
| myEDD-69 | The system should identify and log when users error out of the identity verification process. |
| myEDD-70 | The system should capture the reasons that users are frictioned from Socure. |
| myEDD-71 | If the LOB determines that a claimant needs to complete identity verification, it should make an API call to the myEDD system to determine which identity verification system (Socure or ID.me) the user should be directed to. |
- If the user has previously verified their identity, myEDD should return the user details.
- If the user has been previously referred to an identity proofing system but has not completed identity verification, myEDD should refer the user to the same identity verification system it did previously
- If the user has not previously verified their identity, myEDD should randomly refer the user to either ID.me or Socure
- The myEDD system should allow the bifurcation logic to be configured to a value between 0 and 100. The value should determine the percentage of traffic that is routed to Socure. If the value is 0, all traffic should be routed to ID.me. If the value is 100, all traffic should be routed to Socure.
- If the value is set to 0, all traffic including users previously routed to Socure should be routed to ID.me
- Any users that are flipped from Socure to ID.me should have the stored value in myEDD updated to ID.me
- If the value is set to 100, all traffic including users previously routed to ID.me should be routed to Socure
| myEDD-72 | The myEDD API that is called by the LOB should be configurable to bypass ID-proofing. |
| myEDD-73 | The following attribute should be collected during passive verification: |
Middle Initial
| myEDD-74 | If Socure returns a Refer or Review response, the user should be directed to ID.ME for identity verification (Verify Your Identity Screen) |
| myEDD-75 | Socure should return a Refer response in the following scenarios: |
(If any of the below conditions are met a "Refer" response will be returned)
| • | R110 - Alert List email address match |
| • | R111 - Alert List SSN/ITIN match |
| • | R113 - Alert List phone number match - Concerned that the number could be recycled. These fraud cases are kept for 2 years…so it could be firing on a recycled number. |
| • | R408 - Associated device is likely to be an emulator |
| • | R413 - The device's IP address is more than 3 timezones away from the IP the request is made from |
| • | R606 - There has been minimal activity associated with the phone number |
| • | R614 - Phone number is toll-free |
| • | R625 - Phone number has ported within the past 24 hours |
| • | R627 - Phone number has been ported within the past 7 to 30 days |
| • | R631 - Phone subscriber has been correlated with the input phone number for between 0 and 30 days |
| • | R641 - Proxy is from services that change location to beat DRM, TOR points, temporary proxies, and other masking services |
| • | R645 - IP proxy is TOR-based |
| • | R707 - Address is a commercial mail receiving agency or commercial mail drop |
| • | R708 - Address is a PO Box |
| • | R907 - SSN has been reported as deceased |
| • | R911 - SSN issued prior to DOB |
Scores:
| • | Fraud - ≥ 0.900 | |
| • | Synthetic - ≥ 0.990 | |
| • | Email Risk - ≥ 0.980 | |
| • | Phone Risk - ≥ 0.980 | |
| • | Group 12 (D017) Condition: If All of the conditions exist then | |
| • | R650 - IP address is associated with an anonymizing proxy | |
| • | I633 - IP Connection is business (Is Not Present) | |
| • | I634 - Proxy is an educational institution (Is Not Present) | |
| • | I638 - IP proxy is originating from Google or Apple consumer privacy networks (Is Not Present) | |
| • | I635 - Proxy is registered to a corporation (Is Not Present) | |
| • | Self Attested Attributes 3 (D007) Condition: If All of the conditions exist then | |
| • | Score - Name Phone Correlation (≤ 0.640) | |
| • | Group 5 (D008) Condition: If Any of the conditions exist then | |
| • | Score - Fraud (≥ 0.850) | |
| • | Score - Name Email Correlation (≤ 0.640) | |
| • | Score - Email Risk (≥ 0.940) | |
| • | Self Attested Attributes 9 (D009) Condition: If All of the conditions exist then | |
| • | I922 - Mobile number was not provided at input | |
| • | Group 8 (D010) Condition: If Any of the conditions exist then | |
| • | Score - Name Email Correlation (≤ 0.640) | |
| • | Score - Fraud (≥ 0.850) | |
| • | Score - Email Risk (≥ 0.940) | |
| • | Self Attested Attributes 7 (D011) Condition: If All of the conditions exist then | |
| • | Score - Name Email Correlation (≤ 0.640) | |
| • | Group 10 (D012) Condition: If Any of the conditions exist then | |
| • | Score - Fraud (≥ 0.850) | |
| • | Score - Phone Risk (≥ 0.950) | |
| • | Group 9 (D015) Condition: If All of the conditions exist then | |
| • | I352 - DOB indicates an age over 25 | |
| • | R940 - SSN/TIN not found in public records | |
| • | R922 - DOB cannot be resolved to the individual | |
| • | Group 13 (D018) Condition: If All of the conditions exist then | |
| • | KYC - First Name (0.01 - No Match) | |
| • | KYC - Surname (0.01 - No Match) | |
| myEDD-76 | MyEDD should display a user consent screen prior to capturing the users information for identity verification. |
- If the user does not consent the system should not allow the user to continue.
| myEDD-77 | When Socure executes the passive verification logic, the Review logic will be executed first followed by Refer. Socure will only move on to the Refer logic if none of the conditions are met in the Review logic. |
| myEDD-78 | The system shall support Single Sign-On (SSO) integration via Okta Identity, Credential, and Access Management (ICAM) to enable user access to Unemployment Insurance (UI), Disability Insurance (DI), Paid Family Leave, and overpayment/tax services. |
| myEDD-79 | The system shall validate ICAM account attributes and maintain the relationship between the ICAM user identity and the EDD Customer Account Number (EDDCAN). |
| myEDD-80 | The system shall enable Salesforce to retrieve and validate user identity details (e.g., email address, unique number, application entitlements) from ICAM for authenticated users. |
| myEDD-81 | The system shall store and maintain key identifiers such as SSN, EDDCAN, IVR PIN, and UI WBA in the Portal database to facilitate cross-system access and authorization. |
| myEDD-82 | The system shall provide read access to first name, last name, and DOB as reference-only data, noting the source of truth lies with DI, UI, and Mainframe systems. |
| myEDD-83 | The system shall support batch ingestion and export of ICAM and EDDCAN-related data from and to internal systems including Mainframe, UI Online, and BICC. |
| myEDD-84 | The system shall expose services through Common Interface Services Layer (CISL) for external systems (UI, DI, IVR) to securely retrieve SSN, EDDCAN, and IVR PIN. |
| myEDD-85 | The system shall ensure Common Interface Services Layer (CISL) provides authorized access to ICAM user data including email address, unique ID, and application entitlements without storing BOS PII. |
| myEDD-86 | The system shall monitor and log all Common Interface Services Layer (CISL) interactions for audit and security review. |
| myEDD-87 | The system shall enable authorized EDD staff to view identity-related data (e.g., Name, DOB, SSN/ECN, EDDCAN, CADL, EAN) through the Admin Utility interface. |
| myEDD-88 | The system shall support view-only access with no write privileges through the Admin Utility. |
| myEDD-89 | The system shall support the ability to decode/encode 12-digit obfuscated identifiers printed on physical communications that go out to the customer. |
| myEDD-90 | The system shall enable internal Active Directory authentication for Admin Utility users. |
| myEDD-91 | The system shall support search and access to CA-SIDES employer data via the Admin Utility. |
| myEDD-92 | The system shall receive batch feeds from UI/DI Mainframe systems containing SSN/ECN, Name, DOB, and UI WBA, and update the Portal database accordingly. |
| myEDD-93 | The system shall export ICAM user details (email, unique number) along with SSN/ECN and EDDCAN data to internal EDD systems via EDDCAN Batch. |
| myEDD-94 | The system shall log all batch processing activities and provide error reporting and reconciliation support. |
UI_CSU Complaint App Requirement ID Requirement Bidder Agrees to Meet?
Yes/No.
| UI_CSU_1 | Application Independence and Data Isolation: | |
| • | The system must ensure that the complaint management functionality (e.g., UIB CSU App) operates independently and is not linked to other Contact Center applications. | |
| • | Duplicate Contact records may exist across applications, and the system must not perform cross-app validations. Each application must maintain its own data integrity. | |
| UI_CSU_2 | Case Information Capture |
•The system must support Case records with standard and custom fields to capture contact information, including but not limited to:
oFirst Name, Middle Initial, Last Name oAddress, City oState (selected from a predefined two-character picklist, e.g., CA for California) oZIP Code (numeric, max 5 digits) oPhone Number (numeric, exactly 10 digits) oEmail Address (required field) UI_CSU_3 Reference Number Generation •Upon Case creation, the system must automatically generate a unique identifier, such as the Salesforce Case ID, to be used as a reference number. This reference number must be included in communications with the customer.
UI_CSU_4 Notes and Narrative Fields •The system must support long text fields on the Case object to capture communication-related details, including but not limited to:
oStaff Notes (internal only, up to 2000 characters) oNarrative (customer-submitted content, included in outgoing emails) oReply (staff response, included in outgoing emails) UI_CSU_5 Email Communication Features •The system must support email communication with customers using a fixed “No Reply” email address.
•Users must be able to select predefined email templates, including but not limited to:
oDynamic population of Case fields such as creation date, reference number, narrative, and reply content oStandardized subject lines and bodies oBranding elements such as headers and organizational identity •Templates must support easy maintenance and be stored within the Salesforce email template framework.
UI_CSU_6 Email Activity History •The system must maintain a full history of email-related activity linked to each Case.
•Users must be able to access and review the full content of previously sent emails from the activity log.
UI_CSU_7 Duplicate Emails and Record Creation •The system must allow multiple Case records to be created using the same email address. Each incoming communication must result in a new Case record, regardless of whether the email address already exists in the system.
UI_CSU_8 Case Status Tracking •The system must include a status field to indicate the lifecycle of a complaint. Supported values must include, but are not limited to:
oNew, Pending, Closed UI_CSU_9 Search Capabilities •Users must be able to locate Case records using standard Salesforce global search or list views based on fields including but not limited to:
oContact Name oEmail Address oReference Number UI_CSU_10 User Access and Permissions:
•The system must support user access through group-based permissions. A group named UIB CSU must be created, and all members of this group must have view and update access to all Case records within this application.
•Authorized users must be able to access the application.
LSRT
Requirement ID Requirement Bidder Agrees to Meet?
Yes/No.
| LSRT-1 | The system must provide a search functionality for legislative staff to check if a constituent already exists by entering the constituent’s full or partial name. |
| LSRT-2 | The search bar must suggest matching constituent names based on the entered input and allow selection from the list. |
| LSRT-3 | The system must only display constituents created within the same legislative office as the logged-in staff member in the search result set. |
| LSRT-4 | The search results must include, where applicable, the Date of Birth (DOB) and Phone Number formatted as follows: |
- Example: DOB: 5/1/2001 Phone: (916) 209 -5261
- Example: DOB: 5/1/2001
- Example: Phone: (916) 209 -5261.
If no matching constituents are found, the system must display a message stating "No results."
LSRT-5 Legislative staff must be able to search for cases using one or more of the following criteria:
- Full case number
- Partial case number
- Subject and constituent’s issue related to the case.
| LSRT-6 | The search functionality must return all relevant case numbers matching the search terms, whether the terms match fully or partially with subjects or constituent issues. |
| LSRT-7 | The system must display "No results" if the entered search criteria do not match any existing cases. |
| LSRT-8 | The system must display a section for Recent Updated Cases, showing cases that have been modified by EDD agents. |
| LSRT-9 | Cases in the Recent Updated Cases section must be sorted by the Last Modified Date, with the most recently modified cases appearing first. |
| LSRT-10 | Legislative staff must be able to create a new case for either a new or existing constituent through a user-friendly interface. |
| LSRT-11 | The system must allow legislative staff to view all existing constituents, including their relevant information such as their contact details. |
| LSRT-12 | Legislative staff must be able to view all open and closed cases within their legislative office with appropriate filtering options. |
| LSRT-13 | The system must provide statistics on closed cases to the legislative staff, displaying relevant metrics such as the total number of closed cases, average resolution time, and any relevant trends. |
| LSRT-14 | The system must allow legislative staff to access the Case Details screen when they: |
- Click the Submit button on the Create Case screen and the constituent does not already exist in the system.
- Click the Create Case button on the yellow banner when duplicate case logic indicates that a case already exists for the selected constituent.
- Click the Submit Case button on the Existing Constituent Identified modal when identifiers such as Social Security Number, EDDCAN, and others match.
| LSRT-15 | The Case Details screen must display the full name of the constituent (First Name Middle Initial Last Name) associated with the case. |
| LSRT-16 | Edits made to the Constituent Contact Name from the Edit Case Details screen must reflect immediately in the Case Details screen. |
| LSRT-17 | Changes made by EDD staff to the Constituent Contact Name from the internal portal must also reflect in the Case Details screen. |
| LSRT-18 | The Category field must display the category entered by legislative staff on the Create Case screen, reflecting any edits made from either the Edit Case Details screen or the internal portal. |
| LSRT-19 | The Status of a case must initialize as Open upon submission, transitioning through Open, In Progress, Resolved, and Re-Opened statuses accordingly. |
| LSRT-20 | All edits made to the case Status by EDD staff must be reflected in real-time on the Case Details screen. |
| LSRT-21 | The system must display "Unassigned" for cases in the EDD Agent Queue until an EDD agent is assigned. |
| LSRT-22 | When assigned, the display must show only the first name of the EDD agent. |
| LSRT-23 | Any edits made to the Case Owner field from the internal portal must reflect immediately in the EDD Agent section. |
| LSRT-24 | The Comments section must display all comments added by legislative staff or EDD agents as they are entered, ensuring that the newest comments appear first in ascending order. |
| LSRT-25 | When the case is resolved, the Comments section must include a prefix "Case Resolution Comments" to identify the resolution comments from EDD agents. |
| LSRT-26 | Legislative staff must not be allowed to edit or delete comments made in the Added Comments section. |
| LSRT-27 | The system must allow edits to the Keyword field from both the Edit Case Details screen and the internal portal, reflecting changes in all appropriate views. |
| LSRT-28 | The Keyword field must contain predefined values including "N/A", "Last Paid: [Month]", and "Hardship" options, with "N/A" set as the default. |
| LSRT-29 | The system must update the case status based on edits made by EDD agents in the internal portal and reflect these updates on the Case Details screen. |
| LSRT-30 | When a case status changes to Resolved, the Comments section title must change to "Reopen Case," indicating the possibility to reopen the case. |
| LSRT-31 | The Case Details screen must display the full name of the legislative staff assigned to the case and allow for edits that reflect immediately. |
| LSRT-32 | Changes to the Legislative Staff must only involve staff from the same legislative office as indicated in the case, ensuring proper delegation and access restrictions. |
| LSRT-33 | The Comments/Reopen Case section must allow legislative staff to reopen cases based on their selection of "Yes" or "No" regarding the reopening of resolved cases. |
- Selecting "Yes" must execute the case reopening process while ensuring that no other open cases exist for the constituent.
- If "No" is selected, the case must not reopen; it must maintain its current status until further actions are taken.
| LSRT-34 | Comments made by LSRT agents must display only their first name, while comments by legislative staff must display their full name for clarity in accountability. |
| LSRT-35 | The User field in the Comments section must accurately reflect who posted each comment, ensuring transparency in case management. |
| LSRT-36 | Case Details screen's user interface must be intuitive and consistent with legislative staff's workflows to reduce the learning curve and increase operational efficiency. |
| LSRT-37 | All screens must comply with accessibility standards to ensure usability for all legislative staff members, including those with disabilities. |
| LSRT-38 | Each screen should be optimized for performance, with a maximum loading time of three seconds under standard operation conditions. |
| LSRT-39 | The Constituents List View screen must display a list of constituent records applicable to the legislative office. |
| LSRT-40 | Users must be able to filter constituents based on a predefined criterion and the available options must be displayed instantly upon selection. |
| LSRT-41 | The list view must allow sorting of constituent records based on any of the displayed columns to facilitate quick data analysis. |
| LSRT-42 | The search functionality must allow users to input keyword(s) and return relevant constituent records within two seconds. |
| LSRT-43 | Each constituent name must be clickable and redirect users to the respective Constituent Detail screen. |
| LSRT-44 | The Add Constituent button must be easily accessible and functional, redirecting users to the Create Constituent screen. |
| LSRT-45 | The dropdown for selecting the list view must contain options "My Constituents," "My Office’s Constituents," and "Recently Viewed Constituents," and should respond to user selections swiftly. |
| LSRT-46 | Based on the selection in the dropdown, the appropriate Constituent List View must refresh to show the relevant data without page reload. |
| LSRT-47 | The search functionality must be able to search only the fields of Constituent Name and Phone. |
| LSRT-48 | The system must prevent search through the Last Modified Date field and indicate to users which fields are searchable. |
| LSRT-49 | The Create Constituent screen must enable legislative staff to enter necessary details to create a new constituent record upon clicking the Add Constituent button. |
| LSRT-50 | The Spoken Language field must provide options for English, Spanish, and Other, including a watermark text “Select a Language.” |
| LSRT-51 | The Other Language field must be conditionally editable based on the selection "Other" in the Spoken Language field. |
| LSRT-52 | At least one of the following fields must be provided when Creating Constituent: |
-Social Security Number
-EDDCAN
-Disability Insurance Claim Number -Medical License Number -EDD Client Number -Employer Account Number
| LSRT-53 | The Social Security Number and Employer Account Number fields must enforce security measures, displaying masked content (e.g., last four digits of SSN and opaque Employer Account Number). |
| LSRT-54 | The Constituent Detail screen must allow legislative staff to view the complete details of a selected constituent. |
| LSRT-55 | The Social Security Number must display only the last four digits for security (e.g., XXX-XX-9526) with a clear indication of its secure nature. |
| LSRT-56 | The Employer Account Number must be presented in a fully masked format (e.g., XXXXXXXXXXXX) with an explanation of the security policy. |
| LSRT-57 | The Contact Instructions screen must provide clear instructions for contacting the EDD Legislative Office for constituent detail edits, including a direct link or button. |
| LSRT-58 | The Create Case screen must enable legislative staff to enter information into the case form and create a case for a constituent within their office. |
| LSRT-59 | The screen must provide functionality to notify legislative staff if a case already exists for an existing constituent. |
| LSRT-60 | Users must be able to create duplicate cases for existing constituents and recognize existing constituents during the input process. |
| LSRT-61 | The constituent selection field must allow legislative staff to check for existing constituents by entering their name or partial name. |
| LSRT-62 | Upon locating an existing constituent, available suggestions must prompt legislative staff to select a constituent, which consequently renders the case creation fields as read-only. |
| LSRT-63 | Create Case Screen Read-Only Fields for existing constituents: First Name, Last Name, Phone Number, Date of Birth, Spoken Language, Social Security Number, EDDCAN, Disability Insurance Claim Number, Medical License Number, EDD Client Number, and Employer Account Number fields must remain read-only. |
| LSRT-64 | Create Case Screen Editable Fields for new constituents: Fields: First Name, Last Name, Phone Number, Date of Birth, Spoken Language, Other Language, Social Security Number, EDDCAN, Disability Insurance Claim Number, Medical License Number, EDD Client Number, and Employer Account Number must be editable. |
| LSRT-65 | The Spoken Language field must provide options of English, Spanish, and Other, with a watermark text "Select a Language" while being editable for new constituents. |
| LSRT-66 | The Other Language field must only be editable if "Other" is selected in the Spoken Language field; otherwise, it shall remain uneditable. |
| LSRT-67 | At least one identifier from the following fields must be provided when creating a case for a new constituent or verifying an existing one: |
- Social Security Number
- EDDCAN
- Disability Insurance Claim Number
- Medical License Number
- EDD Client Number
- Employer Account Number
| LSRT-68 | The Employer Account Number must accept input containing between 7 to 15 contiguous numeric digits and display its contents in an encrypted format (e.g., *). |
| LSRT-69 | The system must validate the Employer Account Number, displaying an error message if the input falls outside the required digit length. |
| LSRT-70 | The following fields must remain editable regardless of whether an existing constituent is selected on a case: |
- Keyword
- Subject
- Constituent’s Pronoun
- Constituent’s Issue
- Constituent requires call for resolution
- Category
- Subcategory
| LSRT-71 | The Category must allow options for different types of constituents and include a watermark text “Select Category”. |
| LSRT-72 | The Subcategory selection must depend on the chosen Category and allow legislative staff to move their selection between Available and Selected lists by hovering and using a right arrow key. |
| LSRT-73 | Case Submission Logic |
- Upon clicking the Submit button, the system should validate that all required fields are completed with valid input.
- In the event of no duplicate cases found, the system must successfully create a constituent and a new case.
- If a duplicate constituent is identified, the Existing Constituent Identified modal window must appear, allowing further actions.
LSRT-74 Duplicate Case Handling with Modal Window
- The Existing Constituent Identified modal must activate when an attempt is made to create a new constituent with matching identifiers (e.g., Social Security Number, EDDCAN).
- The First Name, Middle Name, Last Name, and Phone of the identified existing constituent must auto-populate within the modal.
- Legislative staff must have the option to confirm use of the existing constituent's details or proceed with the new entry as needed.
LSRT-75 Case List View Selection - The system shall provide a drop-down menu with options to select the case list view, including:
- All Cases (Open)
- All Cases (Closed)
- All Cases (Closed and Open)
- My Cases
- My Office's Cases
- Recently Viewed Cases
| LSRT-76 | Filtering Functionality - The screen shall allow users to filter cases based on predetermined criteria, ensuring that the filter options are relevant to the selected case list view. |
| LSRT-77 | Sorting Functionality - Users should be able to sort the displayed case list based on any column available in the list. |
| LSRT-78 | Search Capability - The screen shall provide a search function allowing users to locate cases using the following criteria: |
- Case Number
- Constituent Name
- Category
- Subcategory
- Keyword
- Status
| LSRT-79 | The search function shall not support filtering by date and time opened. |
| LSRT-80 | Case Detail Access - Users shall be able to click on a case number to navigate to the detailed view of that specific case. |
| LSRT-81 | Case Reassignment - The screen shall provide functionality for users to reassign cases from one legislative staff to another within the same legislative office via a navigable interface. |
| LSRT-82 | Printing Capability - Users shall have the option to print the selected case list view directly from the screen. |
| LSRT-83 | Dynamic Case View - The case list shall dynamically update to display cases based on the selection made in the drop-down menu for the view. |
| LSRT-84 | Data Integrity - The filtering, sorting, and searching functionalities must execute in a manner that preserves data integrity and provides accurate, relevant results. |
| LSRT-85 | This Reassignment of Cases Screen facilitates the efficient reassignment of cases, ensuring that legislative staff can perform tasks with clarity and ease. |
| LSRT-86 | Current Case Owner Lookup - The system shall only allow the current case owner to look up legislative staff who are active and belong to the same legislative office. |
| LSRT-87 | Enable Find Cases Action - The "Find Cases" button shall become enabled only after selecting a legislative staff member in the Current Case Owner lookup field. |
| LSRT-88 | New Case Owner Lookup - The system shall allow the legislative staff to look up active legislative staff members that are part of the same office and will make the New Case Owner field read-only once reassignment has been completed. |
| LSRT-89 | Reassignment Functionality - The "Reassign Cases" button shall be enabled only when a New Case Owner has been selected. |
| LSRT-90 | Error Handling - If the New Case Owner field is empty, the system shall display a red error banner denoting that this field cannot be empty. |
| LSRT-91 | Success/Failure Notification - Upon reassignment, a result indication (green checkmark or red cross) must be displayed, along with a corresponding success or error message. |
| LSRT-92 | Modal Window for Reassigning Cases - The modal window shall appear upon clicking the "Reassign Cases" button, providing confirmation options for the legislative staff. |
| LSRT-93 | Return Functionality - The "Return to Form" button shall redirection the user back to the Reassign Staff Cases screen without making changes. |
| LSRT-94 | Reassignment Confirmation - The "Reassign Cases" button shall execute the reassignment process and ensure that the results displayed include updated columns indicating success or failure without showing the checkbox column. |
| LSRT-95 | Reassign Cases Modal Window - The modal window shall activate when the legislative staff selects the "Reassign Cases" button. |
| LSRT-96 | The modal shall contain two buttons: |
- A secondary button labeled "Return to Form" for cancellation.
- A primary button labeled "Reassign Cases" to confirm and execute the reassignment.
LSRT-97 After reassignment, the modal shall update the result set to include:
- A result column for success or failure indication.
- A message column displaying either "Success" or the reason for failure.
| LSRT-98 | Upon successful reassignment, the system shall display a green banner indicating success at the top. |
| LSRT-99 | If the reassignment is unsuccessful due to identical current and new case owners, a red error banner shall appear, alerting the user. |
| LSRT-100 | Cases submitted through the Salesforce Community Portal must be automatically synchronized with the EDD Internal System to ensure accessibility for EDD internal staff for processing. |
- The synchronization process must occur in real-time, ensuring that all relevant case details, including constituent information and case status, are immediately available for EDD staff in the System.
- The system must enable EDD internal staff to retrieve and process cases submitted via the Salesforce Community Portal without any delays.
- A confirmation mechanism must be in place to log and track the cases in the internal case management system, providing visibility into the status of each case for audit and reporting purposes.
- All synchronized cases must maintain data integrity and accuracy to ensure that EDD staff are working with complete and correct information.
| LSRT-101 | Dashboard Overview: The user dashboard must provide EDD agents with a clear, consolidated view of key licensing metrics through individual applets. |
| LSRT-102 | Applet Functionality: Each applet displayed on the dashboard must be driven by reports that automatically pull data related to various licensing types used within the organization. |
| LSRT-103 | Licensing Metrics Display: The dashboard must effectively display the following metrics: |
- Total number of active Customer Community Plus Logins.
- Total number of active Salesforce Service Cloud licenses.
- Additional metrics related to other license types as defined by the organizational needs.
| LSRT-104 | Real-time Data Updating: The dashboard must ensure that all metrics are updated in real-time or at defined intervals to reflect the latest licensing data accurately. |
| LSRT-105 | User-Friendly Interface: The dashboard interface must be intuitive and user-friendly, allowing EDD agents to easily navigate and interpret the displayed metrics. |
| LSRT-106 | Applet Customization: EDD agents must have the capability to customize the dashboard layout by rearranging, adding, or removing applets as per their requirements. |
| LSRT-107 | Drill-Down Capability: Each applet must allow users to drill down into detailed reports for in-depth analysis of specific licensing metrics. |
| LSRT-108 | Export Options: Users must be able to export data from the dashboard in various formats (e.g., CSV, PDF) for reporting and analysis purposes. |
| LSRT-109 | Access Control: The dashboard must enforce access controls to ensure that only authorized EDD agents can view and interact with the licensing metrics. |
| LSRT-110 | Notifications and Alerts: The dashboard should provide notifications or alerts to EDD agents for any discrepancies or important changes in licensing metrics, such as nearing license limits or expirations. |
| LSRT-111 | The Legislative Office Home Screen must be accessible only to authorized EDD agents to ensure data security and integrity. |
| LSRT-112 | Recent Records Display: The home screen must prominently display the most recent records, allowing EDD agents quick access to the latest information for timely action. |
| LSRT-113 | Last Modified Cases: The system must provide a section for displaying last modified cases, enabling EDD agents to easily track updates and follow up as necessary. |
| LSRT-114 | Dashboard Applets: The dashboard must include individual applets that display important metrics clearly. These applets should include: |
- Cases Opened by Day
- Open Cases by Category
- Cases Closed by Day
- LAIO – Pending Workload by Work Queue
- User Registration Requests by Month
- Cases by Legislative Office
- Cases by EDD Agents
- LAB Strategic Goal 1
- LAB Strategic Goal 2
- Opened Assigned Cases
| LSRT-115 | Report Generation: Each dashboard applet must be linked to an underlying report that can be accessed by EDD agents for detailed data analysis. |
| LSRT-116 | User Customization: EDD agents should have the ability to customize the layout and visibility of applets on their home screen to suit their workflow and preferences. |
| LSRT-117 | Error Handling: The system must incorporate error handling mechanisms to notify users when there is an issue retrieving data for the dashboard or applets. |
| LSRT-118 | Analytics Tracking: The tool must track user interactions and performance metrics related to the applets, allowing for ongoing assessment and improvement of the dashboard's utility and functionality. |
| LSRT-119 | User Registration Request Approval Access - Only EDD agents with the Legislative Service Referral Tracker (LSRT) administrator permission set shall have access to the User Registration Requests screen. |
| LSRT-120 | Approval Process - The system shall provide an approval process that allows LSRT administrators to approve, reject, or recall user registration requests submitted by legislative staff. |
| LSRT-121 | Request Status Options - The status of user registration requests shall include the following options: |
- None
- Created
- Review In Progress
- Rejected
- Approved
| LSRT-122 | Status Management - LSRT administrators shall set the status of a user registration request based on the approval, rejection, or recall actions taken within the internal portal. |
| LSRT-123 | No Accidental Approvals - The system shall prevent LSRT administrators from accidentally approving a user registration request by requiring confirmation via an Approve modal window. |
| LSRT-124 | Permanent Approval- Approved user registration requests shall not be reversible; once approved, LSRT administrators cannot change the status back to Rejected. |
| LSRT-125 | Contact and User Record Creation - Upon approval of a user registration request, a contact record and a user record for the legislative staff shall be automatically created in the system. |
| LSRT-126 | Contact and Portal User Links - The Contact link and Portal User link shall be provided for legislative staff that have been approved, indicating their record's status as either created or not created based on the approval process. |
| LSRT-127 | Creation Field Verification - The First Name, Last Name, Email, Phone, House, and Legislative Office fields on the User Registration Requests screen shall match the information provided by the legislative staff during registration. |
| LSRT-128 | Reassignment Capabilities - LSRT administrators shall have the ability to reassign user registration requests to another user or queue within the same legislative office. |
| LSRT-129 | Deactivate Portal User Functionality - The Deactivate Portal User button shall be available for EDD agents to deactivate previously approved legislative staff, which will uncheck the Active checkbox on the user record. |
| LSRT-130 | Security Logging - The system shall provide security logs that detail the origin of user registration requests, including IP address, user device, time duration, location, and operating system. |
| LSRT-131 | Notification on Status Changes - The system shall notify LSRT administrators of any status change conducted on a user registration request, ensuring transparency throughout the approval process. |
| LSRT-132 | Error Handling - If a user registration request is rejected or the status cannot be changed, the system shall display an appropriate error message to inform the LSRT administrator of the issue encountered. |
| LSRT-133 | Screen Accessibility: The User Provisioning Staging List View screen must be accessible only to authorized users, specifically designated LSRT administrators and ITB users. |
| LSRT-134 | Record Posting: The system must automatically post a record to the User Provisioning Staging list whenever an EDD agent provisions, deprovisions, or deactivates a user via the User Management Tool. |
| LSRT-135 | User Status Display: The list must display both active and inactive users, providing clear visibility into the provisioning status of each user for EDD agents. |
| LSRT-136 | List Views: The User Provisioning Staging screen shall include two list views: |
- All Users
- Recently Viewed Users Users should be able to switch between these views seamlessly.
| LSRT-137 | Sorting Functionality: The list must have a sorting feature that allows EDD agents to sort the displayed records based on any of the fields available in the list view (e.g., user name, provision date, user status). |
| LSRT-138 | Data Reconciliation: The User Provisioning Staging List View is designed to enable EDD agents to reconcile user data against an external system, ensuring data consistency and accuracy. |
| LSRT-139 | The User Management Tool must be accessible exclusively to authorized personnel, specifically LSRT administrators and assigned users. |
| LSRT-140 | User Provisioning: The tool must provide functionality for provisioning users into the Legislative Office app, allowing authorized agents and administrators to add new users effectively. |
| LSRT-141 | User De-provisioning: The system must allow users to de-provision existing users from the Legislative Office app, ensuring that access rights are properly managed and outdated permissions are revoked. |
| LSRT-142 | User Deactivation: The tool must include a mechanism for deactivating users in the Legislative Office app, enabling administrators and agents to temporarily suspend user access as needed. |
| LSRT-143 | Role-Based Access: The tool must implement role-based access controls, allowing different functionalities (e.g., provisioning, de-provisioning, deactivation) to be used based on the user's assigned persona (agent, manager, administrator). |
| LSRT-144 | User Lookup Functionality: When deactivating users, the tool must provide a user lookup feature to allow agents and administrators to easily select the appropriate user to deactivate. |
| LSRT-145 | Action Logging: All actions taken within the User Management Tool (provisioning, de-provisioning, deactivation) must be logged in the system for auditing and accountability purposes. |
| LSRT-146 | Error Handling: The system must include robust error handling capabilities to notify users of any issues encountered during provisioning, de-provisioning, or deactivation processes, ensuring user-friendliness and clarity. |
| LSRT-147 | Training and Support: The organization must provide adequate training and documentation for LSRT administrators and ITB users to ensure proficient use of the User Management Tool. |
| LSRT-148 | Performance Monitoring: The tool should include metrics or logs to monitor the performance and usage of the provisioning and de-provisioning processes, allowing for ongoing optimization and improvements. |
| LSRT-149 | Security Measures: The tool must implement security measures, such as validation checks, to ensure that only authorized users can perform actions relevant to their roles. |
| LSRT-150 | The Legislative Office Business Account screen must be accessible only to authorized EDD agents who have permission to view and edit legislative office account details. |
| LSRT-151 | View Legislative Office Details: The screen must display comprehensive details about each Legislative Office, including associated legislative staff and their respective roles. |
| LSRT-152 | Edit Permissions: EDD agents must have the ability to edit the legislative office account details, including fields such as name, contact information, and other relevant attributes, within the internal portal. |
| LSRT-153 | Deletion Restrictions: The system must enforce restrictions that prevent EDD agents from deleting any legislative office records, ensuring data integrity and compliance. |
| LSRT-154 | Legislative Staff Association: The system must clearly indicate which legislative staff belong to a particular Legislative Office, determined by selections made during registration via the Legislative Referral Login system. |
| LSRT-155 | Constituent and Case Access: The Legislative Office must dictate which constituents and cases are visible to the legislative staff in the Legislative Referral Login system, ensuring a secure and appropriate scope of access. |
| LSRT-156 | The Entity Type field must display all entities, including the following options for selection: |
- CA Assembly
- CA Lt. Governor's Office
- CA Senate
- CA Treasurer
- U.S. House
- U.S. Senate The system should ensure…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .