S-DASOBO-00014873 RFP ADDENDUM_2_FINAL~1.pdf

Bid Number: S-DASOBO-000014873 – Operations, Maintenance, Data Migration and Enhancement Services

Addendum No. 2

02/13/2026 Page 1 of 13

Level 3 - Restricted

OREGONBUYS BID NUMBER: S-DASOBO-00014873

OPERATIONS, MAINTENANCE, DATA MIGRATION AND

ENHANCEMENT SERVICES

ADDENDUM 2

SECTION 1: PURPOSE

The purpose of this addendum is:

1.1 ADDITION OF ROUND 2 SUBMISSION REQUIREMENTS AND EVALUATION PROCESS

SECTION 2: ROUND 2 SUBMISSION REQUIREMENTS AND EVALUATION

PROCESS

See Page 2 for instructions related to Round 2.

SECTION 3: PROTEST

Protests to this addendum must be submitted in the manner required in RFP Section 4.4.2 and are due 2 Business Days from the publish date and time of this Addendum to OregonBuys®.

02/13/2026 Page 2 of 13

ROUND 2 SUBMISSION REQUIREMENTS AND EVALUATION PROCESS

The following outlines the process and submission requirements for those Proposers in the Competitive Range for Round 2.

A. ROUND 2 OVERVIEW

Round 2 will consist of the following components:

1. Narrative Submission

Full participation in Round 2 is mandatory to remain competitive for Contract award. The following sections outline the Round 2 components in more detail, including submission deadlines, evaluation criteria and submission information.

B. ROUND 2 NARRATIVE SUBMISSION

Proposers shall submit narrative responses to the questions outlined in Appendix 1. Functional Design Documentation, Technical Design Documentation and Data Dictionaries (Round 2 Additional Materials) for the System can be viewed on Box.com. Email the Single Point of Contact (SPC) at sara.stone@das.oregon.gov to gain access.

C. ROUND 2 PROPOSAL DELIVERY

Required Round 2 submissions must be uploaded in OregonBuys® via a Quote Revision. Round 2 Proposers will get a notification from OregonBuys® when the Quote Revision is available. All components of the Round 2 proposal must be uploaded by 3:00 PM PT on March 20, 2026. For questions or issues related to submission in OregonBuys®, please contact the OregonBuys® Supplier Help Desk at support.oregonbuys@das.oregon.gov or 1-855-800-5046.

D. ROUND 2 EVALUATION

DAS SPS will conduct the Round 2 evaluation in the context of State’s procurement practices and rules, including the Round 2 screening and selection criteria; and through observations, review, and analysis of Proposer responses to specific Round 2 functional and non-functional questions and scenarios, including any related follow-up that DAS SPS may require. The Evaluation Committee will also evaluate the Price Proposal. Specifically, Evaluation Committee will:

1. Evaluate Proposer’s proposed Price and other key components of price including but not limited to, proposed SLA’s, Key Persons, number of Full Time Equivalent Staff, Refinements/Refinement monthly hours, and any additional considerations.

2. Evaluate the proposed Solution’s technical quality and expertise, including without limitation demonstrated and perceived flexibility, ability to be scaled, maintained, and updated to evolve with technology, and configurability to meet Oregon-specific needs based on narrative responses provided.

3. Evaluate the maturity and suitability of Proposer’s approaches to development, project management, collaboration, and long-term relationship with the State.

a. Maturity (i.e., defined, optimized, and repeatable processes).

b. Suitability (includes without limitation alignment with State standards and applicable oversight requirements).

4. As needed validate responses to Proposer’s Round 1 Proposal against provided narrative responses in Round 2.

5. Evaluate the suitability and fit of Proposal regarding long-term operations and maintenance.

6. Evaluate Proposers overall professionalism and ability to efficiently and effectively communicate proposal throughout narrative responses.

mailto:sara.stone@das.oregon.gov mailto:support.oregonbuys@das.oregon.gov

02/13/2026 Page 3 of 13

The Evaluation Committee (“Committee”) will distribute points based on Appendix 2.

-APPENDIX 1 STARTS ON THE NEXT PAGE-

02/13/2026 Page 4 of 13

APPENDIX 1

ROUND 2 NARRATIVE RESPONSE QUESTIONS

Question 1 - Level of Effort

For each of the six modifications below, Proposer shall provide (a) assessment of the level of lift,

(b) classification (Support Request / Refinement / Enhancement), (c) estimated effort (full time equivalent “FTE”) and the number of weeks, (d) any key dependencies and assumptions, (e) primary risks and mitigation efforts, and (f) a brief rationale that references the business requirement and technical specification (as identified in Attachment H, Requirements and Round 2 Additional Materials – see Section B, Round 2 – Narrative Submission).

Lift Scale Definitions

• Low – Configuration or minor code changes; up to ~8–16 hours; minimal risk, no architecture changes.

• Moderate – 1 sprint (~2 weeks); contained code changes; minor database or configuration updates.

• High – 2–3 sprints (~4 – 6 weeks); cross-component impacts; data migration or non-trivial integration.

• Very High – 4+ (~8+ weeks) sprints or program-level; material architectural change, compliance implications, or significant successful Proposer coordination.

Classification Definitions

• Support Request – a vendor-managed activity intended to restore, maintain, or stabilize existing functionality of the ODHS & OHA Salesforce System (System) without introducing net-new capabilities. It may include configuration adjustments or minor code changes (“limited modifications”) when necessary to correct System Defects, address regressions, or ensure the System continues to operate as designed.

• Refinement – means a mutually agreed-upon system modification requested by Agency to improve an existing system’s efficiency, performance, usability, or security without altering its core functionality. Refinements may include debugging, streamlining processes, applying minor updates, fine-tuning configurations, or enhancing the user experience. To include all Salesforce required updates.

• Enhancement – means adding new features, capabilities, or integrations to existing to the ODHS & OHA Salesforce System to expand its functionality. Salesforce required updates are not “enhancements” and shall be considered started O&M refinements

-CONTINUED ON THE NEXT PAGE-

02/13/2026 Page 5 of 13

Level of Effort Modification Table

Please, complete the table below for each System Modification Scenario (1-6). Add short, precise rationales referencing the business requirement and/or technical specification.

System Modification Scenario #

Level of Lift (low Moderate / High / Very High)

Classification (Support / Refinement / Enhancement)

Estimated Effort (FTE-weeks)

Key Dependencies Assumptions

Primary Risks & Mitigati ons

Rationale (tie to BR & Tech Spec)

Example: Low Refinement Moderate 1- 2 weeks

Insert any Dependencies or assumptions that are made in coming to this conclusion

List any risks or mitigati ons that will be made or consider ed when preform ing work

Any additional comments, plus rationales of how Proposer came to these conclusions referencing appropriate Business Requirement (attachment H), Functional Data Dictionary, Data Dictionary, or Technical Data Dictionary that led Proposer to making this conclusion.

02/13/2026 Page 6 of 13

System Modification Scenarios

SYSTEM MODIFICATION #1: Updating Supervisor Email whenever Manager field on User Profile Changes

Issue: Notification Emails are going to an incorrect supervisor (one who is inactive in CAM side of the System).

Business Need: Update the Supervisor E-mail field on the case whenever there is a discrepancy between the case and the case owner's user record regarding the supervisor's email.

Business Requirement: Create a new automation driven from the user record to check if the supervisor has changed. This automation will update the Supervisor E-mail on all owned Cases and Reconsiderations whenever a change is made to the supervisor field in the user’s profile.

Approach: Below is a list of Email Alerts that currently send emails to the Owner and Supervisor for Investigation or Reconsideration. Replace the use of the Email Alert (Supervisor Email field) with Email Content composed directly within the Flow. This approach allows recipient email addresses to be added dynamically within the Flow and enables Agency to deprecate the Supervisor Email fields from the Intake / Investigation and Reconsideration objects.

• Central Office Adult Protective Services (COAPS) Final Investigation Closure Notification

• Central Office Adult Protective Services (COAPS) Investigation Closure Return Notification

• Rejection Notification to APS Supervisor and APS Unit

• Reconsideration Final Order Issued Notification to Investigator and Supervisor

SYSTEM MODIFICATION #2: Health Info fields moved from Intake/Investigation to Victim Record

Issue: All of the Health Concern fields exist on both the intake and the person account. Programs would like to look into removing the fields for Health Concern off of cases and intake screens and have that data saved and maintained on the Alleged Perpetrator (AP) and Alleged Victim (AV) person records. Snapshots of the data at the time of the Intake would need to be saved for historical records. The danger symbol would need to be seen on the intake screens for informational purposes and the messages pointing the User to update the Person Records with any changes to Health Concerns would need to still be active.

Business Need: Intellectual Developmental Disabilities (IDD)/Behavioral Health (BH)/Office of Training Investigation and Safety (OTIS) or Aging and Peoples with Disability (APD) users must not have the ability to view or edit Health Information fields on Intake and Investigation screens.

However, users should still see a message directing them to the Person Record for verifying and recording any changes, ensuring awareness and maintenance of accurate Health Information. Fields will be moved to the Victim and AP for each of the associated person records for the Snapshot at Case Closure.

Business Requirement: Create new 'Read-only' Victim Health Information fields and section on the Victim object. The section title should include the message 'Modify and view most current details on Person Record'. Backup and migrate records from the Intake/Investigations Details over to the new fields on the Victim object. Update automation to allow changes and updates to the Victim Health Information on the Victim's Person/Service Provider record to be reflected on the Victim record. Once a case is closed, the Intake/Investigation Snapshot automation should capture a final record of Victim Health Information at the time the case is closed.

Approach: Victim Health Information fields are specific to the individual victim on a case.

Therefore, Victim Health Information fields should be moved from the Intake/Investigation details page directly to the Victim record.

02/13/2026 Page 7 of 13

SYSTEM MODIFICATION #3: Salesforce Permission Set Reconfiguration

Issue: Salesforce has announced end-of-life for managing object, field, and user permissions directly on Profiles beginning with the Spring ’26 major release. While Profiles will continue to exist, permissions such as object Create, Read, Update, and Delete (CRUD), field-level security (FLS), user permissions, Apex access, connected apps, and record types (non-default) will be controlled exclusively through Permission Sets and Permission Set Groups.

The current CAM configuration relies significantly on Profile-based permissions, with some automated assignment of Permission Set Groups based on user record fields. Without proactive restructuring, the system risks misalignment with Salesforce platform changes and increased administrative and security risk.

Business Need: The Agency must ensure continued compliance with Salesforce’s evolving permission model while maintaining secure, role-based access across the System, and related programs. Permission assignment must remain scalable, auditable, and aligned with program responsibilities, particularly given delegated administrator involvement in user provisioning.

Failure to realign permissions may result in access inconsistencies, security gaps, or operational disruption following future Salesforce releases.

Business Requirement: Reconfigure the existing permission architecture so that:

• All object, field, and user permissions are migrated from Profiles to Permission Sets and/or Permission Set Groups.

• Profiles are retained only for login hours, IP restrictions, default record types, default apps, and page layout assignments (until fully replaced by Dynamic Forms/App Builder).

• Permission Set Groups are evaluated and structured either on a one-to-one basis with existing profiles or modularized into functional groupings to allow more flexible assignment.

• Existing automation that assigns Permission Set Groups based on user record attributes is evaluated and expanded where appropriate to ensure consistent and automated permission provisioning.

• The resulting configuration maintains appropriate separation of duties across programs and supports audit transparency.

Approach: Conduct a comprehensive inventory of existing Profile-based permissions and map them to new or restructured Permission Sets and Permission Set Groups. Utilize Salesforce migration tools, as available, to support conversion. Evaluate whether to mirror existing profiles directly or decompose them into modular Permission Sets aligned to job functions. Update user-driven automation to support expanded permission set assignment logic. Perform regression testing to ensure no unintended access elevation or restriction occurs prior to deployment.

SYSTEM MODIFICATION #4: Standardized Monitoring, Error Handling, and Reconciliation for DBAmp Integrations

Issue: The existing two-way integration between the data warehouse and Salesforce (SSIS + DBAmp extracts and upserts) relies largely on legacy processes and ad hoc troubleshooting.

When data issues occur, there is no consistent, platform-wide mechanism in Salesforce to detect failures, document root causes, or track resolution.

Business Need: State teams need reliable, transparent, and repeatable processes for identifying and resolving data discrepancies so that Salesforce System remains trustworthy for case work, licensing, reporting, and emergency response across programs.

02/13/2026 Page 8 of 13

Business Requirement: Create a standardized integration oversight framework within Salesforce that:

• automatically captures failed or rejected DBAmp transactions in a structured log or object,

• links errors to affected System records where possible,

• supports triage and assignment to the appropriate data or admin team, and

• records whether the correction occurred in the source system, warehouse, or System.

The solution should also distinguish between:

• routine O&M data corrections, and

• issues that require refinements or enhancements to the integration.

Approach: Leverage existing SSIS/DBAmp processes to feed error signals into the System (e.g., via scheduled jobs, error tables, or middleware notifications). Create a lightweight Salesforce workflow (object + flows + queues) for tracking integration failures, documenting root cause, and confirming resolution. Align the workflow with existing agency data management practices, including defined roles for data review, correction, and escalation, and ensure compatibility with current documentation and audit tracking expectations.

SYSTEM MODIFICATION #5: Consumer Type Segmentation for Maps, Lists, and Event Add Flows

Issue: Multiple consumer populations are being brought into Emergency Response management System (ERM) for mapping and event work. As additional consumer types are added, users risk seeing consumers outside the population they are responsible for when viewing Maps, running lists, or adding consumers to an event.

Business Need: Different groups need to pull and work consumer lists independently (including on Maps and within events), while ensuring users only see the consumer populations relevant to their role. This supports efficient outreach, reduces confusion, and avoids mixing populations in reporting and event operations.

Business Requirement: Implement consumer type segmentation so that Maps, consumer list pulls, and “add to event” actions can be filtered by consumer type and constrained by user group.

At minimum:

• Support multiple consumer types (example: In-Home, Behavioral Health, Older Americans Act).

• Ensure users only see consumer types they are authorized to access across Maps and list outputs.

• Ensure event-level actions that pull consumers into an event also honor the same consumer type constraints.

• Provide a consistent user experience so that users do not have to manually filter out consumer types they should not be working.

Approach: Introduce a consumer type attribute and apply it consistently across the ERM mapping layer, list generation, and event consumer selection logic. Configure sharing, permissions, or other access controls so that consumer visibility aligns with user group responsibilities. Ensure reporting and map views are aligned so that consumer types are segmented by default rather than requiring manual filtering.

02/13/2026 Page 9 of 13

SYSTEM MODIFICATION #6: ERM Event Deletion Cleanup for Rapid Assessment and Related Records

Issue: As ERM has scaled to support multiple overlapping emergency events per consumer and facility, deletion of an Emergency Event does not always leave related ERM data in a consistent state. In some cases, Rapid Assessment values and certain child records persist even when a record is no longer associated with any active event; in other cases, downstream automation can re-populate cleared values.

Business Need: State teams need ERM Consumer and Service Provider records to reliably reflect current event relationships. When a deleted event is the last remaining event tied to a consumer or provider, all ERM-specific fields and related records should clear in a predictable way so users are not acting on stale emergency information in Maps, lists, or reports.

Business Requirement: Modify ERM deletion behavior so that when an Emergency Event is deleted:

1. Conditional field clearing o ERM-related fields on associated Consumer and Service Provider records clear only when the deleted event was the sole remaining associated event.

o Rapid Assessment fields on the Consumer record follow the same rule.

2. Child record alignment o Related ERM child records created for that event are removed or updated under the same “last-event” criteria (e.g., Consumer Needs, Facility Resources, Evacuation Sites, and other event-specific ERM records).

3. Automation safety o Cleanup logic avoids recursive or competing automation (e.g., “Previous Level” logic or other derived fields must not repopulate values once cleared).

4. Scale and limits o The System is able to continue handling high volumes of related records without breaching Salesforce governor limits, even for large, multi-county events.

5. Multi-event behavior o When a consumer or facility remains tied to other active events, their Rapid Assessment data and ERM fields should persist appropriately rather than being fully wiped.

Approach: Apply a consistent “last-event deletion” rule across Consumers and Service Providers using a scalable mechanism that coordinates triggers, flows, and any batch processing needed to respect Salesforce limits while preventing automation conflicts.

Question 2 - S-Docs:

We use S-Docs as a managed app in Salesforce to generate reports and documents. Proposer shall describe how it would set up and run S-Docs for Agency, addressing the following briefly:

1. Setup: How would Proposer install S-Docs and configure access (Lightning, permissions, profiles).

2. Templates & Data: How would Proposer design templates that pull data from related records/reports, including conditional sections and repeatable line items.

02/13/2026 Page 10 of 13

3. Automation: How documents would be generated via Flow or Apex (e.g., on stage change or by button click), and how Proposer would avoid duplicates.

4. Output & Delivery: Where outputs are stored (Files/Content Version), formats (PDF/DOCX), naming, and email delivery.

5. Security & Compliance: How would Proposer ensure FLS/sharing is respected, log/audit generation events, and handle sensitive data.

6. Support & Performance: How would Proposer handle errors, monitor volumes, and optimize for large datasets.

7. Effort & Roles: A high-level effort estimate, and the roles required (admin, developer, architect).

Question 3 - Pricing Information:

Proposer shall provide a proposed pricing structure for the Operations & Maintenance (O&M) Integrated Services Contract. In the response, include the following details:

1. Pricing Model:

o Overall cost structure (e.g., fixed price, time & materials, tiered pricing).

1. Including annual cost & proposed increases (if any) for a 6-year contract (contract may be extended and may be renewed every 2 years) o Any assumptions or conditions tied to pricing.

2. Staffing Plan:

o Total number of full-time and part-time staff included in price proposal.

o Roles and responsibilities for these resources.

o How Proposer’s team will coordinate with and support two separate state O&M teams.

3. Refinement Releases:

o The number of refinement releases per month included in price proposal.

o Any limitations or constraints on refinements (e.g., scope, complexity, hours per release).

o Process for prioritizing and approving refinements.

4. Proposed Service Level Agreement (SLA):

o Define response time for acknowledging requests.

o Define resolution time for completing requests or resolving issues.

o Describe any escalation procedures for urgent or critical issues.

o Include any additional SLAs proposed as part of Proposer’s pricing agreement (e.g., performance metrics, reporting cadence)

5. Additional Considerations:

o Describe Proposer’s process for handling urgent changes or out-of-scope requests.

02/13/2026 Page 11 of 13 o Describe any cost implications for exceeding refinement limits.

Question 4 - Customer Management:

The System is funded by two financial agencies: OHA and DHS. Describe Proposer’s staffing and governance model that ensures both funding agencies’ priorities are met without compromising cross-agency needs. Specifically: How will Proposer structure teams, set decision rights, and run prioritization so each funding agency feels adequately supported? Also, describe Proposer’s approach to resolving conflicts when stakeholder groups believe their needs are not being addressed.

-END OF APPENDIX 1-

02/13/2026 Page 12 of 13

APPENDIX 2

ROUND 2 SCREENING AND SELECTION CRITERIA

All Round 2 components will be independently evaluated by members of an Evaluation Committee (“Committee”). The Committee is comprised of scoring members (“Scorers”).

Committee members may change, and there may be additional or fewer evaluators for different aspects of Round 2 demonstrations and interviews. Scorers will assign a score from 0 to 100% based upon the guidelines listed above in Table 1.1: Scoring Guidelines. This table provides guidance to the Committee concerning their required qualitative assessment of how well a Proposer addresses the elements and essentials prescribed in each scored submission requirement.

The SPC will average all scores for each evaluation criterion. The average score becomes the final score and will be used as a percentage multiplier of the maximum possible points for that criterion. The SPC may request further clarification to assist the Committee in gaining additional understanding of Round 2 submissions. Unless requested, clarifications will apply to all Proposers.

A response to a clarification request must be to clarify or explain portions of matters already submitted and may not contain new information not included in the original submission.

Table 1.1: Scoring Guidelines

SCORE EXPLANATION

90 – 100% OUTSTANDING – Response (including conduct, demeanor, and verbal and written contributions from participating Proposer personnel) meets submittal requirements, demonstrates exceptional knowledge of the subject matter, and demonstrates excellent ability to deliver the requested service.

61 – 89% GOOD TO VERY GOOD – Response (including conduct, demeanor, and verbal and written contributions from participating Proposer personnel) meets submittal requirements, demonstrates thorough knowledge of the subject matter, and demonstrates an ability to successfully deliver the requested service.

50 – 60% SATISFACTORY – Response (including conduct, demeanor, and verbal and written contributions from participating Proposer personnel) meets submittal requirements, demonstrates basic knowledge of the subject matter, and demonstrates an ability to minimally deliver the requested service.

1 – 49% POOR TO FAIR – Response (including conduct, demeanor, and verbal and written contributions from participating Proposer personnel) meets submittal requirements but does not demonstrate satisfactory knowledge of the subject matter or does not demonstrate an ability to deliver requested service.

0% RESPONSE OF NO VALUE – Response is unacceptable and does not meet the minimum requirements.

02/13/2026 Page 13 of 13

SCORED COMPONENT POINTS

QUESTION NO. 1 – LEVEL OF EFFORT 300

QUESTION NO. 2 – S-DOCS 350

QUESTION NO. 3 – PRICING INFORMATION 1,300

QUESTION NO. 4 – CUSTOMER MANAGEMENT 200

TOTAL 2,150

-END OF APPENDIX 2-