Survey Response Approvals is a new functionality available in Surveys that enables admins to decide whether they want to isolate changes made through a specific survey, ensuring that these changes only reflect in the graph after receiving approval from the administrator.

Enterprise architects, particularly in large enterprises, must adhere to stringent data governance policies. Isolating changes until they are approved by data owners ensures the quality and integrity of the data, boosting trust in the architecture.

Here's a step-by-step process you need to follow to enable response approval for a survey:

While creating a new survey or editing an existing one, switch on the response approval toggle in the ‘General Information’ section of the survey.

2. Save and Set Survey Live:

Save the changes made to the survey and publish the survey to set it live.

3. Initiate Responses Collection:

Whether using Broadcast or any other channel to request changes, launch the responses collection process and await the initial feedback. It's important to note that broadcasts operate with the 'mainline' version of the data and do not account for pending responses from surveys.

4. Navigate to Surveys Overview:

Visit the Surveys Overview page to access pending changes.

5. Access Pending Changes:

To view the pending changes for a survey, click the three-dot menu on the survey and select ‘Response approval’ to navigate to the response approval page.

On the Response approval page, you will find the list of all changes that need approval.

Pending Changes

On the Response approval page, you also have the option to reset all pending changes. Clearing all pending changes will prevent any components from being updated, created, or deleted. Please be aware that once cleared, these changes cannot be recovered.

6. Approve or Reject Changes:

Click on the component to review and either approve or reject the changes. The survey change requests are grouped by component, including the pending changes to references, which are grouped under the component they are connected to.

These are the changes you can approve or reject on a component:

Review and either approve or reject the changes. The survey change requests are grouped by component.

When using the standalone survey interface (survey module not integrated into Ardoq Discover), survey respondents will notice a "Pending changes" tag next to the component name, both on the survey page and the component page when submitting the survey:

And then "Pending approval" tag on the page of component when submitting the survey.

It's important to note that the "Pending approval" tag will only be displayed if changes have been previously applied to the component fields and haven’t been reviewed as part of the specific survey. Additionally, approval surveys are conducted independently; if there are pending changes for the same component across different surveys, the responses and statuses in one survey will not be visible in another. For example, if a user reviews the same component as part of a different survey, the "Pending approval" status will not be visible. For example, if a user changes the price of Application X through the Application Details survey, another user viewing Application X through the same survey will see the "Pending approval" tag and the latest cost change. However, if the user reviews Application X through the Application Cost and Allocation survey, they will see the old price of the application, and no "Pending approval" tag will be added.

If a survey is sent via broadcast to a targeted audience, individuals from this audience will find a list of components with pending changes in the "Pending Approval" section of the My Tasks page:

Additionally, users can see that certain component changes are pending approval by opening the component page through a survey connected to the viewpoint:

Tracking responses as an administrator-approver.

One of the existing limitations is that the administrator's name will be shown in the survey response log instead of the name of the person who proposed those changes.

An administrator will not see the survey submissions in the broadcast progress bar until such a response is approved.

Tracking approvals as a contributor-respondent.

At this moment, survey respondents are not notified whenever the survey response they submitted has been approved or rejected. We're evaluating the need for this.

However, contributors will be able to differentiate between questions with pending approvals and those that no longer have pending approvals: Once the survey is submitted, the component will be marked as "Pending Approvals," even though it will be placed in the "Complete" folder on the My Task page in Ardoq Discover. Once the survey changes are approved, the tag will disappear.

Only users with the administrator role have the authority to approve changes. However, users with other roles can enable or disable response approvals for a survey if they have survey privileges. While they can see the “Pending Changes” tab on the survey overview page, access to this section is restricted.

While changes made by multiple users to the same field in the same survey won't be reflected in the graph until approved by the admin, the survey respondents will see the latest changes made by them or other users to the field on the page of the component.

The admin, a person responsible for approving the change, will only see the latest version of the changes too.

For example, if user A makes changes to a survey field that requires approval, and later, before an admin reviewed the changes, user B opens the component, they will see the changes made by user A. After user B changes the field value, the previous value will be overwritten in the survey interface and the new value will appear for both users. However, neither of these changes will will be applied to the live data until the admin approves the latest one: When the administrator reviews change approvals for this component, they’ll see only changes done by user B. The changes done by user A will be visible in the Survey Response Log.

Here are the next steps we're considering to evolve this feature: