REVISED-RFI- Reimbursable Work Authorization Processing Replacement-05-09-2024.pdf

PDF 420 KB Posted

Attached to
Reimbursable Work Authorization (RWA) Processing Replacement
Solicitation number
47HAA024N0008
Issued by

About this file

This document is a Request for Information (RFI) issued by the U.S. General Services Administration (GSA) for market research and information gathering purposes. It does not represent a solicitation or request for proposal.

The RFI seeks information from industry on systems and platforms available to improve the automation and management of Reimbursable Work Authorizations (RWAs) for the GSA's Public Buildings Information Technology Service and the PBS Office of Project Delivery Reimbursable Services. An RWA is an interagency agreement where a client agency reimburses GSA for services provided. The RFI outlines the functional, technical, and security requirements for a potential solution, and requests vendors provide information on their capabilities, technical approach, estimated costs, integration with existing GSA systems, and experience. Responses are due by 1:00 PM EST on June 17, 2024. The government will not pay any costs associated with responding to this RFI.

View the file

Other files

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

General Services Administration (GSA)

Office of Administrative Services (OAS)

Office of Internal Acquisition (OIA)

Request for Information (RFI) 47HAA024N0008

Reimbursable Work Authorization (RWA) Processing Replacement in support of

GSA IT - Office of Public Buildings Information Technology Services and

PBS - Office of Project Delivery Reimbursable Services

NAICS code 541519

Revised: May 9, 2024

Disclaimer 3

1. Introduction 3

2. Background 4

3. Description of Need 5

3.1 Functional Requirements 6

3.2 Technical Requirements 7

3.3 Additional Security Requirements 9

4. RFI Response Requirements 9

5. Generic Cost Estimate 11

6. RFI Submission Instructions 11

7. Final Comments 11

Public Records and Request for Confidentiality 11 Copyrights 11 Content of Responses 11 Cost to Vendors 12 No Obligation to Issue Request for Quote 12

Appendix 1: System Definitions (as referenced in Figure 1) 13 Appendix 2: Vendor Questionnaire 14

1.0 General (Question-Based Requirements) 14

2.0 Other Capabilities 16

Disclaimer

This Request for Information (RFI) is for planning purposes only and is not a Request for Quotes (RFQ), Request for Proposals (RFP) or an obligation on the part of the Government to acquire any services.

Responses to this RFI are not offers and cannot/will not be accepted by the Government to form a binding contract. The Government reserves the right to determine how it should proceed as a result of this notice. Furthermore, those who respond to this RFI should not anticipate feedback with regard to their submission. However, the government may engage vendors that respond to this notice by seeking further information about capabilities. The Government will not pay any cost incurred in response to this RFI. All costs associated with responding to this RFI will be solely at the responding vendor expense. The information provided in this RFI is subject to change and is not binding on the Government.

1. Introduction

The U.S. General Services Administration (GSA) is engaging our industry partners in the formative stages of our requirements for contractual support. The Office of GSA Information Technology (GSA IT) - Public Buildings Information Technology Services (PB-ITS) and the PBS Office of Project Delivery Reimbursable Services are looking for ways to better meet the challenges inherent to the growing variety of interfaces, increasing IT capabilities, demanding security needs, and rising expectations of customers. We invite the industry to suggest ideas in technology and business practices that will help us move to the next level of service.

This RFI aims to gather information on systems and platforms available in the marketplace to improve the automation and management of Reimbursable Work Authorizations (RWA). An RWA is an interagency agreement between PBS and a customer agency whereby PBS agrees to provide goods and/or services and the customer agency agrees to pay PBS for the cost of the goods and/or services, including PBS’s indirect costs and fees. Any above-standard service not included in a Rent agreement but requested by the client agency is reimbursable, and thus, PBS must receive an RWA from the client agency to fund these additional services. The solution shall allow GSA customers to submit work requests, which are routed to various POCs for review, processing, and approval, resulting in a formal interagency agreement, an RWA, to execute the requested work.

Responses shall provide a detailed description of the vendor’s proposed solution to address the questions and technical requirements below. The solution can comprise multiple applications and systems, but it shall provide an integrated user experience. The Government prefers to utilize out-of-the-box SaaS or COTS features or templates over fully custom-built solutions.

Preferred solutions are easily configurable to meet unique needs, provide flexibility in process execution, manage changes efficiently and quickly, do not require customization so that software patches and updates are easily applied, and have the ability for super users to make some changes rather than relying on developers to make all changes. Some solutions currently available to GSA include Appian, ServiceNow, Oracle Analytics Server, Tableau, and MicroStrategy for reporting and dashboard solutions.

Responses shall address how the solution will answer the business questions listed in the Vendor Questionnaire in Appendix II. In addition to describing your technical approach, responses must include estimated costs to develop and maintain the solution, assumptions that aid these estimates, and a timeframe to develop, configure, and implement the solution.

Responders shall state whether their solution is FedRAMP certified or if it can be run on premise. If the solution is not FedRAMP certified or cannot be run on premise, then the responder shall be willing to comply with stringent IT Security requirements, which includes implementing controls specified under the Federal Risk and Authorization Management Program (FedRAMP) for cloud service offerings for a moderate system .

2. Background

The Public Buildings Information Technology Service (PB-ITS) is a service within GSA IT that specifically supports GSA’s PBS. PB-ITS develops, deploys, and maintains IT solutions to support multiple PBS business lines in their mission to deliver effective and sustainable workplace solutions to Federal agencies at the best value. Best-value workplace solutions are, in part, achieved due to innovative and effective approaches to project execution, collaborative relationships between national and regional offices, and accurate and timely information made available to project teams and internal and external stakeholders.

The RWA system enables internal GSA and external customer agency users to initiate, amend, review, digitally sign, and submit work requests, Reimbursable Work Authorizations (RWAs or GSA Form 2957) and RWA cost estimates entirely online. An RWA is an agreement between PBS and a customer agency whereby PBS agrees to provide goods and services; and the customer agency agrees to reimburse PBS for the cost of these goods and services. RWAs capture and bill customer agencies for the cost of altering, renovating, repairing, or providing services in spaces managed by PBS for the Federal community over and above the basic operations financed through the rent. The current system, in conjunction with GSA’s financial system captures and bills GSA customers for the annual $2 billion cost of altering, renovating, repairing, and providing services over and above the basic operations financed through rent. The RWA systems customers’ RWA information is captured on the RWA 2957 form either manually or through the automated workflow. This form is signed by both the customer and GSA and is a binding agreement, which defines the scope of work as well as billing and payment terms.

https://www.fedramp.gov/assets/resources/documents/FedRAMP_Security_Controls_Baseline.xlsx

The RWA system captures RWA information and sends most of that information to the financial system in real-time. The GSA financial system is used to record all financial activity: record obligations and expenses, manage invoicing and receivables, and bill and collect from customers.

It pulls the actual RWA financial results from the financial systems.

3. Description of Need

The RWA system is a web-based system that serves Public Building Service (PBS) as a centralized repository for managing Reimbursable Work Authorization (RWA) information. It manages PBS active RWAs via the GSA Form 2957 and includes the ability to:

● Create, modify, and close RWAs in real-time

● Access the original RWA and subsequent amendments on-line; and

● Review and report obligations, commitments, costs, and balances

In order to effectively manage an RWA throughout its lifecycle, the application has multiple functions:

● Add a new Work Request/RWA: Through the current system, users are able to add and submit a new Work Request/RWA to the system.

● Provide data validation: the system quality controls the data entry done by users and ensures all required data is complete and accurate before allowing the package to move to the next phase

● Modify / Amend an existing RWA: through the current system, users are able to modify or amend an RWA that has already been submitted to the system.

● Oversee an RWA: Regional Administrators and System Administrators (SAs) are able to administer RWAs.

● Search for RWA information: the current system users can search for specific RWA data.

In most cases, the user is able to enter the data directly in the field or click a search icon to enter search criteria.

● Add/Modify/Delete Estimates: users can add, modify, and delete estimates in the current system against their own RWAs.

● Upload documents: Users can upload support documents to the current system as the official system of record for all RWA information

● Run Reports: reports provide visibility into the status of all RWAs and data of individual RWAs.

● Automated communications and reminders: the current system creates and sends emails and formal letters to notify customers and GSA users of required action or status changes of an RWA

● Manage Contacts used throughout the RWA process

● Provide audit and compliance needs

● The current system is used by GSA customer agencies, GSA employees (to make requests), and internal GSA employees to manage/process requests.

3.1 Functional Requirements

In addition to what is described, the response shall include how the proposed solution will address the questions stated in Appendix 2 . Please provide responses to the questions in Appendix 2. The responses will count towards the maximum page count.

Business Functionalities:

○ Create and maintain work requests

○ Assign points of contact and other user roles

○ The ability to create and maintain different types of WRs and RWAs.

○ The ability to automate the process to request services.

○ The ability to create and maintain various templates of Cost Estimates for all

RWAs, including application of a variable fee

○ Allow fee structure to be defined and configurable by the Admin based on multi-factor data

○ The ability to manage customer communication associated with RWAs and

Estimates

○ Ability to upload, edit and permanently house record documents

○ A module to define, configure and manage formal Audit Reviews The ability to

Review Financial Information to analyze RWA data and run reports

○ Allow nearly all fields to be validated using complex business rules against data in other parts of the system and against data from other GSA systems

○ Ability to allow regional administrative users to maintain a subset of business rules and some workflow functionalities

○ Ability to modify workflows, form templates, document templates, email and letter templates and business rules from the front end by the national admin without a system release (example: estimating form template)

○ Allow users in any user role to search all data, history, documents associated, and actions for all RWAs and Estimates

Data User Stories:

○ The ability to manage documents and customer communication associated with

RWAs and Estimates

○ Database design

○ The ability to run reports, both standardized reports and ad hoc user generated reports and the ability to save custom user reports for future use.

○ Allow users to export search results and reports into excel and other common formats

○ Allow users to export dashboard visuals into PDF and other common formats

○ The ability to have multiple dashboards that provide quick access, visualization and useful information, both for cumulative data and user specific data

○ The ability to migrate all existing records into the new system even if they are incomplete or conflict with current business rules.

○ Allow glossary, help text, text in errors, etc to be modified by the admin without a system release

Customer User Stories:

○ The ability to access the system through login.gov to search, download, and enter data related to their Agency's RWAs.

○ Ability to route RWAs for internal customer approvals before submitting to GSA.

Ease of Use Capabilities:

○ To have a solution that allows me to search a specific area of the system by using specific parameters related to the selected area

○ To have a solution that provides lookup functions throughout the data entry process

○ To have a Glossary that is easy to access

○ To have a system that is intuitive and easy to use

○ To have a flexible solution that is compatible with mobile devices

○ Allow users to select specific tailored workflows to streamline data entry and modifications

○ System should perform follow up actions to contact customers and allow customers to respond with a binary action via email (without logging into the system)

○ Provide lookup functionality for fields to allow users to search for data based on other data

3.2 Technical Requirements

Technical Functionalities:

○ The system shall have a minimum uptime and availability of 99.5%. This excludes scheduled maintenance windows, which must be communicated to the users in advance.

○ The system shall acknowledge reported issues within 4 hours or receipt during normal business hours. GSA will work to resolve reported issues within 16 hours of acknowledgement during regular business hours

○ The system shall meet all required security controls to achieve Authority to Operate (ATO)

○ The system architecture shall allow changes to be made with ease, ensuring minimal impact throughout the system and minimal cost to implement.

○ The ability to integrate with GSA, SaaS/PaaS systems, and other Federal Agency systems as depicted in Figure 1 below. See Appendix 1 for more information.

○ The system should integrate with the PBS Portal and Sailpoint for authenticating and authorizing the current system users

○ The ability to control access by user roles, modules, user identification information, and system field.

Seamless integration with existing PBS systems and applications via APIs (preferred when available), or ETLs from our 19c Oracle Data Warehouse, or possibly directly from PBS systems, which are a mix of custom built, SaaS - such as IBM Tririga and Kahua, and PaaS solutions - such as Salesforce and Appian. See Figure 1 and Appendix 1 for system information.

● The proposed solution must be WCAG 2.0, 2.1, 2.2 Section 508 compliant.

● Authentication mechanism should use SAML 2.0.

● Hosting Options: If proposing a SaaS solution, FedRAMP certification is preferred or the system must be able to run on premise. FedRAMP moderate controls must be adhered to for cloud based solutions.

● The system shall adhere to security requirements listed in NIST 800-53 to receive an authority to operate (ATO).

● User Interface and User Experience Requirements:

○ The vendor shall provide expert guidance and direction on user experience (UX) strategy, research, and design.

○ The vendor shall create designs that use the U.S. Web Design System and, when applicable, align with GSA’s design system.

○ The vendor shall conduct usability and user acceptance testing on new designs, features, content, navigational elements, etc. to ensure a quality end-user experience.

○ The solution shall incorporate robust accessibility principles into design, and testing for all products to deliver high-quality digital experiences to users of assistive devices.

https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

Figure 1: High-Level View of PBS Systems

3.3 Additional Security Requirements

● Reference 1 CIO 21001M GSA Information Technology (IT) Security Policy

● Reference 2 IT General Rules of Behavior CIO 2104.1B CHGE 2

● Reference 3 Continuous Monitoring (ISCM) Strategy OA Program [CIO IT Security

12-66 Rev 3]

● Reference 4 CIO IL-20-91 Enterprise Identity, Credential, and Access Management

(ICAM) Policy

● Reference 5 CIO 2200.1 Privacy Act Program

● Reference 6 - IT Security Procedural Guide: Security and Privacy Requirements for IT

Acquisition Efforts (CIO-IT Security-09-48)

4. RFI Response Requirements

All interested parties shall furnish the following information:

● Name of Company

● POC, Telephone Number(s), Address, Website and Email Address

● Applicable Contract Vehicles (e.g., GSA Schedule, GWAC, BPAS, etc.)

● Unique Entity Identifier (UEI) Number 1

● Business Size

● High level description of client base for similar services

○ Do you have one current client of similar services and size?

○ Do you have one former client of similar services and size?

● Number of customers

○ Geographic distribution of customers

○ Who is your largest customer?

○ Potentials for conflict of interest in the customer base.

● Length of experience

● If proposing a solution with multiple applications and systems, provide detailed experience and success as a system integrator

● A detailed narrative (vendor capability statement) addressing the Government’s stated need and how your company can fulfill the requirements through your proposed solution(s). Generic responses are not acceptable.

○ Response shall include the solution’s capabilities to integrate with GSA’s existing data

■ Preferred method(s) of integration

1 If you are already registered in SAM.gov and have a DUNS number, most likely you have automa�cally been assigned a UEI number.

https://www.gsa.gov/system/files/CIO%2021001N%20GSA%20Information%20Technology%20Security%20Policy%2009-21-2022.pdf https://www.gsa.gov/system/files/CIO%2021001N%20GSA%20Information%20Technology%20Security%20Policy%2009-21-2022.pdf https://www.gsa.gov/directives-library/gsa-information-technology-it-general-rules-of-behavior-4 https://www.gsa.gov/system/files/CIO%2021001N%20GSA%20Information%20Technology%20Security%20Policy%2009-21-2022.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-137.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-137.pdf https://www.gsa.gov/system/files/CIO%2021001N%20GSA%20Information%20Technology%20Security%20Policy%2009-21-2022.pdf https://www.gsa.gov/directives-library/enterprise-identity-credential-and-access-management-icam-policy-1 https://www.gsa.gov/directives-library/enterprise-identity-credential-and-access-management-icam-policy-1 https://www.gsa.gov/system/files/CIO%2021001N%20GSA%20Information%20Technology%20Security%20Policy%2009-21-2022.pdf https://www.gsa.gov/directives/files?file=2023-07/CIO%202200.1%20GSA%20Privacy%20Act%20Program%20(5-12-2020).pdf https://www.gsa.gov/system/files/CIO%2021001N%20GSA%20Information%20Technology%20Security%20Policy%2009-21-2022.pdf https://www.gsa.gov/system/files?file=Security-and-Privacy-Requirements-for-IT-Acquisition-Efforts-%5BCIO-IT-Security-09-48-Rev7%5D-07-25-2023.pdf https://www.gsa.gov/system/files?file=Security-and-Privacy-Requirements-for-IT-Acquisition-Efforts-%5BCIO-IT-Security-09-48-Rev7%5D-07-25-2023.pdf

■ Examples of your experience with integrating multi-platform and on-premise federal data

■ Approach for addressing both ingress and egress of data

■ Description of how data is stored for normal use cases and how it will store historical records that will not have data for some required fields

○ Response shall provide data integration capabilities of SaaS, COTS, GOTS products. Examples include:

■ The solution can read and display APIs in real time, display it and use it along with transactional data without performance issues.

■ The solution can store and accept input data only through nightly loads and needs to store data locally and only then display it.

■ The solution is flexible and it can do both.

■ The solution can only read from sources but cannot store data.

○ Include assumptions or exceptions

● A response to each of the questions in the Vendor Questionnaire ( Appendix 2 ). Please number your response to reference the question being answered (e.g., 1.0 #1).

● A high-level schedule for the deployment of the solution/system including security approvals. (Important: FedRAMP moderate controls must be adhered to for cloud based solutions, and is the responsibility of the vendor.)

5. Generic Cost Estimate

Provide a Rough Order of Magnitude (ROM) estimate to develop, configure, and maintain the proposed solution based on GSA’s requirements. What are the anticipated “best guess” annual maintenance and other costs/fees? List any assumptions made based on the requirements listed in this document. Please provide for years one through five.

The estimate shall include all products/services. Also provide your cost structure for different integration methods supported by levels of complexity (small, medium, large), along with assumptions on how levels of complexity were defined. If there are any licensing costs, please include the cost model and licensing information.

6. RFI Submission Instructions

Any questions regarding this RFI should be emailed directly to the contracting Officer, Erica Pelham, erica.pelham@gsa.gov no later than 11:00 AM EST, Tuesday, May 28, 2024, subject:

RFI 47HAA024N0008-RWA Wednesday, May 15, 2024.

Vendors shall submit responses to the RFI via email, no later than 1:00 PM EST, Monday, June 17, 2024 Friday, May 31, 2024 . Responses shall be submitted to the Contracting Officer, Erica Pelham at erica.pelham@gsa.gov , mailto:erica.pelham@gsa.gov subject: RFI 47HAA024N0008-RWA. Responses shall not exceed 25 pages . All responses shall be typewritten and presented in MS Word or PDF format (minimum of 12 point, Times New Roman or Arial font). Vendors may provide additional materials relevant to the RFI (e.g., screenshots, etc.) as attachments outside of the 25 pages, for a maximum of 10 additional pages.

If applicable, title your screenshot according to the question/statement being referenced (e.g.,

1.0. #1).

NO TELEPHONE INQUIRIES.

7. Final Comments

Public Records and Request for Confidentiality Any document submitted that contains confidential information must be watermarked as containing confidential information, and each page upon which confidential information appears must be marked as containing confidential information. The confidential information must be clearly identifiable to the reader wherever it appears.

Copyrights By submitting a response, the vendor agrees that the government may copy the response for purposes of facilitation of review or to respond to requests for public records. The vendor certifies that such copying will not violate any copyrights in the materials submitted.

Content of Responses Responses should be based on the material contained in this RFI and any other relevant information the vendor thinks is appropriate. Responses will not be returned.

Cost to Vendors The government is not responsible for any costs incurred by a vendor in relation to the preparation of a response to this RFI.

No Obligation to Issue Request for Quote The issuance of this RFI does not obligate the government in any way to issue an RFQ for the services described.

Appendix 1: System Definitions (as referenced in Figure 1)

Customer Unique Entity Identification - available data includes a unique identifier for customers as well as other procurement data. The data is available via a public API.

Financial Data - available data includes financial transaction data. This is a SaaS solution and the data is available via a reporting database.

Award Information - available data includes procurement award information. This data is available via an Oracle 19c Data Warehouse.

Building Inventory and Profile Data - available data includes key attributes on leased (7,088) and owned buildings (2,157) that spans 369 million square feet of space as well as lease processing and lessor payment information on 8,087 active leases. It is on-premise, custom built on Java, and runs on an Oracle 19c database.

Cost Estimate Data - available data includes national parameter-based planning and early-design phase cost estimates for new construction, R&A, land ports of entry, and modernization projects for GSA PBS owned and leased assets. Cost estimates are for design cost, construction costs, and building maintenance / repair costs. A breakdown of estimated costs for a specific project are provided. It is cloud based and built on Salesforce.

Occupancy Agreement Billing Data - data available includes rental invoice information. It is on-premise and custom built on Java and Oracle 19c.

Energy & Water Usage Data - available data includes both energy and water usage history annually, compound annual change usage, usage relative to R5 average, environmental impact data, technology: renewable energy systems in the building. It is on-premise and custom built on Java and Oracle 19c.

Work Items - data available includes work items and their estimated costs for a building. It is on-premise and custom built on Angular JS and PostgreSQL 14.4.

Financial Data - Transactional data from GSA’s financial systems and customer invoicing data available through an Oracle database.

Construction Project Management data - available data includes enterprise-wide construction and project management information for PBS projects above and below the prospectus threshold in both owned and leased space. It is built on Kahua, a cloud based SaaS system.

Occupancy Agreement Management, Building & Space Inventory - data available includes occupancy agreements and space assignment information such as: s pace and parking used by the client agency, space costs, rental rates, and other related information in a rental agreement. It is built on IBM Tririga, a cloud based SaaS system.

Lease Acquisition Management and Documents data available includes leased project data -when a tenant will be moved into another building (acquisition and expiration of leases used for schedules and investment planning. It is on-premise and built on Appian 21.2 with custom code and runs on MySQL 5.7.

Appendix 2: Vendor Questionnaire

Please provide your responses to the questions below as part of your RFI response. The responses to these questions are part of the maximum page count.

1.0 General (Question-Based Requirements)

1. How does your solution handle a work item / record that has multiple statuses, multiple possible workflows and moves between internal and external user groups for action?

2. Can the solution be configured to allow internal users to edit region-specific data and work items / records based on their user role permissions in conjunction with a combination of data/status limitations of the record?

3. How granular are your access control capabilities? For example, can edit access be set at varying combinations of the field level, information type, step in the process, project level, or other?

4. Can the solution audit all records for inactivity and then flag / create a review action item / automate an action for the inactive record(s)?

5. How does the solution present hidden/conditional fields which become available when other fields are modified? Are they disabled until relevant or hidden until relevant?

6. Can an admin user make a new conditional field that is dependent on specific business rules and parameters?

7. Can an admin user see where the conditional fields and the information in each of the fields are sourced / informed (view business rules and relational dependencies as a flowchart or table)?

8. Does the solution allow users to send a flat file (.csv) or other web services with the APIs? What types of data do the APIs handle and are there any size limitations?

9. Does the solution utilize a service center / help desk? If yes, how is it managed?

10. If the help center is managed on the backend, can admin users access the service center and manage it?

11. Can the solution ingest emails or data / input from emails? Are users able to customize the email, from the solution, so email receivers only need to click a button in an email to take action/respond? This would be comparable to approving a share request via Google by clicking the button and possibly changing the sharing rights in the dropdown all from the email request and does not require opening the document (or logging into the system).

12. Does the solution allow a package/request to repeat steps and move backwards in the process? If yes, are all steps of the process saved/viewable or are only the latest actions in a step recorded?

13. Does the solution have a historical reference for users to see a history of the changes to a package of information? If yes, can the user view side-by-side comparisons of multiple draft or accepted versions? Can the solution display and highlight changes / differences?

14. How does the solution log all edits for records with lots of fields or key fields, which require edits throughout the record’s lifecycle?

15. How does the solution validate data based on the business rules for a use case?

16. How does the solution’s business rule engine handle conflicting rules?

17. How does the solution handle management of package workflows and can a super user modify and configure workflows (without system programming)?

18. Can super users create new and modify document templates and automatic notifications

(emails, PDF attachments)?

19. The system will need to be able to present users with a series of questions to help QC packages. Can super users insert additional fields or QC questions into the package workflow as a front end configuration?

20. How configurable are the dashboard views from an internal and external users’ perspectives? Please provide visual examples of a dashboard displaying financial activity data for internal and external users.

21. Please provide a description of the solution’s ability to customize reports and create ad hoc reports. Please describe the differing privileges and the ability of an admin user to customize the queries needed for a report.

22. Can users save searches / create savable custom reports?

23. Can custom reports include a page describing the report’s search parameters (similar to a

SQL query including the query in the file with the search results)?

24. How do internal and external users authenticate? Can your solution integrate with login.gov?

25. Does the system have a robust notification system to alert users when a record reaches a specific status or an action is required based on admin defined business rules? How does the notification system integrate with email notifications and does it include a documentation repository of the notifications sent via email?

26. Can admin users view / see all the notifications sent for a specific project or to all users associated with that project?

27. How does the solution handle role hierarchy? And how does the solution handle users with overlapping roles and various regions / user groups?

2.0 Other Capabilities

1. Serve as a centralized repository where users can view, edit, upload and store RWA data and information to include images, files, attachments, data, metrics, financial statements, etc.

2. Calculate figures, allow users to enter data and act as the system of record for designated data fields and documents.

3. Provide visualization of data sets to include graphs, charts, maps, etc. and allow users to filter results based on selected criteria.

4. Reports should be exportable (Excel and PDF) enhancing accessibility and usability.

5. Data should be accessible to be consumed by other applications (APIs are GSA’s preferred method).

6. Reports and dashboards should be at the asset, building, regional, and national levels which capture, aggregate and summarize critical information, including project status, financial performance, budget data, physical condition, and tenant details. If applicable, please provide any URL to a demo of your product.

File details come from the government source that posted it. Updated .