Important Update: Community URLs redirect issues are partially resolved. Learn More. .

cancel
Showing results for 
Search instead for 
Did you mean: 
Hemanth
Archer Employee
Archer Employee

 

The Archer Engage customers had no visibility on the progress made on a request published to Engage until its submission. Knowing the progress made on a published request is crucial for Archer customers. It provides transparency, allowing stakeholders to stay informed, and take proactive action to get requests completed on time. Managing users on an inflight Engage request is another important aspect that the Archer Engage customers were interested in. This helps in addressing situations when a request owner in Engage leaves the organization or when the request is sent to a non-intended recipient.

We are pleased to announce the availability of both the above-mentioned capabilities in our latest feature release, Engage 4.2.0.

To provide visibility into published requests on Engage, the requester from the customer organization will now have access to those requests. The requester is the Archer contact person mentioned in the request during publish.

This feature does not require any new configuration changes. At the Archer end, we use Archer contact person which is an existing mandatory field to publish a request. Hence, this feature does not require any Archer or Engage agent upgrade.

Hemanth_0-1705397005794.png

 

After the Engage 4.2.0 release, any new requests published with requester details will be visible to the requester. Requesters will receive a one-time email notification informing them that they have been granted requester access in Engage. On clicking the link in the email, the requester will be directed to either the login flow or the sign-up flow, based on their user status in the portal.

Hemanth_0-1704681338291.png

Requesters can only see those requests where they have been added as a requester during publish. Requests sent to vendors (Engage for Vendors) will be shown under Vender Requests and requests sent to internal users (Engage) will be shown under Internal User Requests. The requestor can switch between these two pages from the hamburger menu on the Engage portal.

Hemanth_2-1704686172558.png

 

Hemanth_1-1705397155894.png

 

The vendor requests dashboard page lists both the open and submitted assessments in a separate section. It has the following request details.

  • Identifier - A unique request identifier used to identify a request.
  • Name - Name of the application/questionnaire.
  • Vendor Name - Name of the vendor organization (only seen in Vendor Requests Dashboard).
  • Owners - The Owner(s) of the request (only seen in the Internal User Requests Dashboard).
  • Due - Due date of the request.
  • Progress - The progress made on the request.
  • Actions – The Manage participant link.

Sorting, filtering, and pagination are supported for applicable columns. We have also provided an option to the requester to select the Archer instance for which they want to see the requests. The Archer instance can be switched from the provided drop-down. If there are multiple instances with the same name, then the instance can be identified based on the request identifier and the instance can be selected. This selection will be saved automatically, on the selection of the instance.

Clicking the Manage Participants icon, under the Actions column will open the Participants page. This page lists the participants for that request, along with the title having the request identifier, request name, and vendor name for vendor requests (the internal user requests will have the request identifier and request name). The following participant details will be displayed:

  • First Name - First name of the participant.
  • Last Name - Last name of the participant.
  • Email - Email address of the participant.
  • Role - The role of the participant (Contributor/Owner) for that request.
  • Actions – Ability to either edit or remove a participant from a request.

 

The requestor can add new participants, edit, and remove existing participants from the request. Engage users are also provided with the option "Back to Dashboard" to navigate them back to the dashboard page. 

Hemanth_2-1705397256872.png

 

To add a participant, click "+". A popup window appears, and the requestor can fill in the participant details to add the participant. The requester can add participants from any domain. Note that the autosuggestion will not appear for the requester to make sure that they add the intended recipient by providing the correct email ID as they are allowed to add participants from any domain.

Another enhancement made is in adding participants. The participants of the assessment can add participants from all the existing participant domains in that particular assessment.

Hemanth_0-1704687474420.png

 

To edit, the edit icon must be clicked. Only the role of the participant can be edited through this option. A Requester can change all participants’ roles to contributor. A warning message is displayed on changing the last owner’s role to a contributor.

Hemanth_1-1704688534727.jpg

 

To remove a participant, click the delete icon. A confirmation popup appears to remove the participant from the request. The requester is allowed to remove all the participants from a request. A warning message is displayed before removing the last participant.​

Hemanth_2-1704688824740.png

 

Key Considerations

  • An Agent upgrade or Archer upgrade is not required to utilize the power of this feature.
  • The requester can add participants from any domain to a request.
  • The notification email for the requester will be sent only once per user, on the first successful publish after upgrading to Engage 4.2.0. 
  • Although the requester can see the progress and manage participants of a request, the requester will not be able to see the content (questions) of the request.
  • Notification email will be in English if the requester has not signed up in the Engage portal. It will be in the user profile language of the portal if the requestor has already an existing user in the Engage portal.
  •  Autosuggestion is not provided for the requester during the addition of a participant.​
  • If there is a single instance in the Vendor Requests/Internal User Requests page, then that would be selected by default. If there are multiple instances, then the first instance from the query result will be selected.​ There is no specific sorting of instance list.

 

Known Limitations/Behaviours

  • The requests that are published before Engage 4.2.0 will not be listed in the requester-related pages in the Engage portal.
  • There is no filtering/sorting support on the manage participants page as there will be a limited number of participants per request.