Skip to main content
RFP Settings let you configure organization-wide defaults for the RFP workflow. Navigate to Settings > RFP settings. Settings are grouped by topic: filling, intelligent assignment, answer profiles, review and approval, the Answer Library, attachments, tags, projects, Go/No-Go dimensions, and permissions.

Filling

Default RFP assistant

Choose which AI assistant is used by default when filling RFP cells. Users can still override this per project, but the default applies to all new RFP projects. Use the Default RFP Assistant dropdown to pick a public assistant. If the selected assistant is deleted or made private, a warning will appear prompting you to select a new one.

Spreadsheet import instructions

Choose Edit to provide import instructions (up to 5,000 characters) for future Excel/CSV files. Save your changes, or clear the field and save to restore default behavior.

Intelligent assignment

Intelligent assignment suggests responders, and with Realm Intelligent Suggestions also reviewers, for unassigned questions when an RFP is activated. Suggestions are only suggestions: anyone who can assign questions on the RFP accepts or dismisses them, and nobody is assigned until then. You need permission to manage organization settings to change this section. See Suggested responders and reviewers for how they look on an RFP.
  • When an RFP is activated: Choose Suggest people to get suggestions, or Do nothing to choose everyone by hand. Do nothing is the default.
  • Suggestions come from: Choose where suggestions come from.
    • Our assignment policy follows the policy you write below. It suggests responders only.
    • Realm Intelligent Suggestions suggests the people who answered and reviewed similar questions in your completed RFPs. It suggests both responders and reviewers (reviewers only on RFPs with reviewers turned on), and uses the policy below as a fallback for responders it can’t place. It becomes available once your Answer Library has at least 100 answers from at least 5 completed RFPs. The section shows how many your organization has so far.
  • Assignment policy (called Fallback policy when suggestions come from history): Describe in plain language who should get which questions, and @mention the people and teams to suggest. For example, “Assign all sales-related questions to @Sales, everything else to @Sara”. With Our assignment policy, nothing is suggested until the policy mentions at least one person or team.

Teams in suggestions

A policy can mention teams as well as people. A question the policy gives to a team gets that team as its suggested responder, and accepting the suggestion assigns the question to the team. Realm Intelligent Suggestions only suggest individual people, so teams appear in suggestions only through the policy.

Answer profiles

Answer profiles are named styles for how RFP answers are written. Each profile combines two settings, and they apply to every generated answer, whichever assistant fills the RFP:
  • Answer length: Choose Concise for short answers that cover the pertinent facts, or Detailed for answers that explain how each requirement is met using the specifics in your sources.
  • Instructions: Free-form instructions applied to RFP answers only, for example tone of voice, terminology, spelling conventions, or which product the answers should focus on.
Create as many profiles as your RFPs need, for example one for enterprise RFPs and another for security questionnaires. One profile is the organization default, marked with a Default badge. It applies to every RFP that has not picked a profile of its own. Use the menu on a profile to edit it, set it as the default, or delete it. The default profile cannot be deleted; promote another profile first. When a profile is deleted, RFPs that used it switch to the organization default. Profiles apply at three levels. The organization default covers everything, an RFP can pick its own profile in the RFP’s settings, and a section can pick its own in the bar shown when filling. Each picker shows the profile currently in effect, so a section that has not been given one of its own shows the RFP’s profile, and an RFP that has not been given one shows the organization default. See RFP-level settings. When you regenerate a single answer, the regenerate panel has a profile control of its own. It applies to that one answer and leaves the section’s profile alone.

Test a profile

Open Test this profile in the profile editor to see what the profile produces before you save it. Type an RFP question, or select Use a real question to search the questions in the RFPs you have access to, then select Generate answer. Searching covers the questions in your Answer Library, so you can test the profile against the wording your customers actually use. Those questions come from RFPs you have finished, so a brand new organization sees none yet. Examples next to it offers a short list of generic questions to use instead. The answer is generated the same way a real RFP fill generates it, searching your organization’s sources. Nothing is saved: no RFP is changed and the answer is not added to the answer library. When you have unsaved changes to the profile, the sandbox shows two answers side by side, one from the saved profile and one from your draft, so you can compare them before saving.

Review and approval

Require explicit approval for export

When enabled, each row in the RFP must receive explicit approval before they can be exported. When disabled, RFPs can be exported at any time without requiring approval. This is a default for new RFP projects. Individual projects can override this setting.

Approving rows

Approving rows is not part of the permission matrix. RFP owners and admins can always approve, and so can project members and the person assigned to a row. When you turn on Enable reviewers in RFP settings, questionnaires gain a Reviewer column and the assigned reviewer for a row can also approve it. Individual RFPs can override the organization default with the Reviewer column setting in their own RFP settings. Turn on Only reviewers can approve rows in RFP settings to limit approval to a row’s assigned reviewer, RFP owners, and admins. Members and assignees can then no longer approve rows, and only RFP owners and admins can mark an RFP completed from its options menu, since that also approves every row. The setting applies only to RFPs that have reviewers turned on.

Answer Library

Make all RFP answers public

Realm extracts question-answer pairs from completed RFPs into a searchable answer library. Normally, answers extracted from an RFP in a restricted project are only visible to that project’s members. When this setting is enabled, everyone in the organization can find all indexed RFP answers in search and chat, including answers from restricted projects. Enabling or disabling the setting takes effect immediately.

Restrict Answer Library editing to admins

By default, any user can add or remove RFP answers from the answer library. When this setting is enabled, only organization admins can edit the answer library. The setting covers every route into the library, including correcting it from a chat.

Only add approved rows to the Answer Library

Realm extracts question-answer pairs from an RFP once it is completed, and by default it takes every row, whether or not the row was approved. When this setting is enabled, only approved rows are extracted. Rows still pending or in review when the RFP is completed are skipped, so an RFP finished with some rows unresolved does not teach the answer library from them. Imported past RFPs have no review step, so all of their rows are still extracted. The setting applies from the moment it is turned on. Answers already in the library stay there until the RFP they came from is extracted again.

Answer age limit

By default, filling an RFP can reuse any answer in the Answer Library, however old. With an age limit set, answers whose source RFP was completed longer ago than the limit are not used when filling new RFPs. The answers are not deleted. They stay in the Answer Library, and knowledge search and chat still find them. Only RFP filling skips them.

Tags

Create, rename, recolor, and delete organization tags here. See browsing knowledge for how tagging affects search. Tags narrow answers to specific source material. An RFP carrying a tag draws answers only from sources tagged the same way, plus the supporting files of its own project that have Use in responses on, and a project’s Go/No-Go analysis draws evidence only from sources tagged like the project. Use tags for subject matter, such as a product area. In chat and when filling an RFP, Realm also sees each source’s tags, so it can tell which product a source describes. Choose files picks the connections, folders, and files a tag covers. Check a folder to include its contents, then clear the checkboxes for nested folders or individual files to create exceptions. Changing a parent clears its child selections. Direct file assignments remain independent of folder exceptions; an explicit file exclusion takes precedence. Right-click an item and choose Use inherited selection to clear its individual choice. Scope changes affect already indexed files immediately; new files still need to finish indexing. Under RFPs, checking an RFP adds the tag to the RFP itself, the same as its Tags column in the RFP list. Open an RFP to tag only some of its sections or answers instead. Always in scope keeps a tag’s content searchable for every RFP, whatever tags that RFP carries. Use it for general material such as company background. It cannot be added to a project. On an RFP, it can be added once the RFP is completed or imported, which shares that RFP’s answers with every other RFP. It can be removed at any time.

Projects

Create RFPs in projects only

When this setting is enabled, the button on the RFPs page creates a project instead of a standalone RFP, so every new questionnaire is filled inside a project. RFPs that already exist outside a project are not affected: they stay in the list and can still be opened, filled, and exported.

Project visibility

Controls who can access projects across the organization:
  • Public by default: new projects can be accessed by everyone in the organization. Each project can still be restricted individually.
  • Private by default: new projects are only shown to project members, but a member can make a project public afterwards.
  • Always private: projects are only shown to project members and cannot be made public. Selecting this mode also makes all currently public projects private.

Permissions

Any member can manage RFPs

RFPs that are not part of a project can normally only be managed by their owners (the person who uploaded them plus any co-owners) and organization admins. Managing covers renaming, archiving, deleting, setting the deadline, and changing settings such as the assistant and languages. When this setting is enabled, every member of the organization who can view such an RFP can also manage it. RFPs inside a project are not affected: any project member can already manage them.

Project roles

By default, project members can do almost everything project owners can. The permission matrix lets you restrict a small set of capabilities, for example limiting them to project owners:
  • Manage project members
  • Delete projects
  • Mark an RFP completed
The matrix shows roles as columns and these permissions as rows. Use the checkboxes to enable or disable a permission for each role. The Owner role is built-in and always has all permissions. Organization admins can always do everything in every project, regardless of their project role. You can create additional custom roles to match your team’s workflow. To create a role, click Add Role, give it a name, and configure its permissions. To edit or delete a role, use the buttons in the matrix header. Changes are batched, so you can edit multiple permissions and save them all at once.

RFP owners and ownership transfer

An RFP can have more than one owner. Every owner has the same rights as the person who uploaded the RFP: managing it, marking it completed and reopening it, and editing the owner list. Owners are managed from the RFP’s options menu under Manage owners. For RFPs inside a project, project owners can also edit the owner list. Anyone who can access the project can become an owner, including people who have access through the project’s general access setting. The owner picker lists only those people. Ownership can also be transferred. Owners > Transfer ownership in the RFP options menu hands the RFP to another user, for example when the current owner leaves or goes on vacation. The previous owner stays on as a co-owner until removed. Deadline reminders and summaries follow the new owner. Projects can be transferred too: a project owner or admin can pick Transfer ownership in the member list under Project Settings.