Important Update: Archer Community Scheduled Maintenance on November 23–24 - New Community Launching Soon! Learn More..
We are pleased to announce the availability of Archer Engage Portal 4.3.0 with Engage Agent 3.2.0.
Archer Engage and Engage for Vendors release 4.3.0 and Engage Agent release 3.2.0 includes the following enhancements:
With this feature, we are enabling Archer Engage customers to attach files during request publish to push the files into the portal. This helps customers in providing more context to the vendors or internal users while responding to the requests. Before this release, the attachments uploaded in Engage portal were flowing back to Archer. With this release, we are supporting bidirectional flow of attachment files.
There is no configuration required at Archer end to support this feature. Engage agent 3.2.0 or above is required to support this feature.
Any attachment file type supported in the Archer Control Panel can be attached in the request and published. On the portal, the attachment files published from Archer are visible. Engage portal allows certain file types to be uploaded by Engage users. These file types are called supported file types on the portal. The Engage portal still allows users to upload attachment file types that were supported in previous versions. Here is the list of supported file types for reference:
Attachment file types that are not supported by the Engage portal are still visible on the portal when published from Archer to the portal. These files can be downloaded and/or deleted from the portal but cannot be uploaded from the portal. The size of the attachment and the number of attachments that can be added to the portal is determined by the configuration done for that field on the Archer platform.
After submission, attachments in Archer will reflect the same list of attachments submitted by the Engage users. Any attachment removed by the Engage user in the portal will also be removed from Archer after submission.
If the Archer customer wishes to preserve the published attachments, they can utilise two separate fields. One field would store the attachments published from Archer to the Engage portal, which should be set as read-only on the portal. When this field is read-only, attachments can be downloaded but not deleted. Another field would capture attachments added or updated by Engage users. This approach ensures the integrity of the original published files.
We are enabling Archer customers to have more visibility into the inflight requests periodically. The status and progress information of the published requests will be synced back to Archer every 24 hours, outside of business hours, based on the portal region.
The Archer platform version has to be upgraded to version 6.14.0.2 or above and the Engage Agent has to be upgraded to version 3.2.0 to utilize the power of this feature.
There are 3 numeric fields introduced to know about the progress of the published requests.
We have introduced two additional values in portal status to know the status of published requests in Archer.
Note that the newly added portal status values will not be available by default. To add these values, the customer must install a package available on community. No other configuration is required for status.
The actual responses of the request will not be retrieved back to Archer during this cycle. The retrieval of responses will happen on submission only.
The configuration can be done either from the Engage configuration tab or with a custom object.
First, we will look at how to configure the progress fields from the Engage configuration tab. Three new fields highlighted in the image below were introduced in Archer version 6.14.0.2 under the field mapping section of the Engage configuration tab. Numeric fields must be selected from the dropdown for all three fields to capture the corresponding information.
Note that all three fields are optional and the publish or retrieve process will not be affected by this. Also, these fields can be configured independently. For example, if you just want to use the Engage Progress field, you only need to select the corresponding field in the Engage configuration tab and it gets the Engage progress from the portal.
If a custom object is used, then the following keys should be used for configuring the progress-related fields. The values for the keys are the field IDs of the numeric fields.
Visible Fields: VisibleFieldsFieldId
EngageProgress: EngageProgressFieldId
Required Fields Remaining: RequiredFieldsRemainingFieldId
After configuration is complete and the request is published, the status and progress information of the inflight request which had been opened or updated in the last 24 hours will be synchronized back to Archer.
Note that this interval is different from the submitted request retrieve interval.
If status and progress-related fields fail for requests because of metadata change or any other reason, the same set of requests will not be considered for updating in the next sync cycle, unless the requests are updated again in the portal.
Before this release, the history log for request submission from Archer Engage used to capture all the participants even when the request was submitted by any of the owners of the request. With this release, the Engage history log captures only the details of the Engage user submitting the request, rather than all participants.
In the following image, three participants are added to a request and published.
Once the responses are added to the request and submitted on the portal, only the Engage user's details who submitted the request will be captured as shown below:
This release introduces UI enhancements for My Company Requests and My Customer Requests page to support pagination. Engage users can also select the number of requests that can be loaded in the above-mentioned pages.