Senior Integration Developer | 2025

Introduction

Integrating with Archer, a leading risk management platform, presents significant challenges for developers, particularly when working with subforms. The complexity of Archer’s API and data structure often leads to extended development timelines and increased maintenance burdens. This white paper explores how Estrelica.Core, a specialized .NET library, dramatically simplifies and expedites integrations with Archer, focusing on a real-world example of automatically generating Finding records from Questionnaire Comments subforms. By leveraging Estrelica.Core, development time was reduced by over 90%, resulting in a more efficient and maintainable solution.

Challenges in Working with Archer Subforms

Archer’s APIs are notoriously difficult to work with when handling subforms due to:

Estrelica.Core: A Game-Changer for Archer Integration

Estrelica.Core was designed to simplify and optimize integration with Archer by providing:

Use Case: Automating Finding Records from Questionnaire Comments

Problem Statement

An organization was transitioning their TPRM program from another software platform and was looking to streamline their new process for raising Findings based on responses to a risk assessment (questionnaire). While gathering input from the company’s stakeholders, CastleHill proposed using the Questionnaire Comments subform to allow end-users to flag assessment responses quickly and conveniently. After the creation of a comment subform on the assessment record, a solution was needed to automate the creation of Finding records based on user comments within the Questionnaire Comments subform in Archer. Manually extracting subform data and generating corresponding Finding records proved to be time-consuming and error-prone.

Generating the Finding records automatically proved to be difficult. Due to the dynamic nature of the assessment questions and the nested structure of the comments to assessments made reporting difficult, so using an advanced report as a source was not viable. This ruled out the ability to use an Archer-to-Archer data feed. Using Archer APIs for a more customized solution was a better option long-term, but since querying subform records and their relationships is burdensome, the effort required to develop and maintain such a solution was unreasonable. A customized integration was necessary but would need to be developed in a way that was both efficient and simple to maintain long-term.

Solution with Estrelica.Core

By utilizing Estrelica.Core, the organization developed a streamlined solution:

Code Example

Below are three examples, taken from this use case, which display how Estrelica.Core simplifies working with the Archer APIs.

1. First, a search is required for ‘flagged’ subform records (flagged by a values list field set to “Yes”). Normally, performing this search via the Archer APIs would require several steps. After authenticating, search xml would need to be built out which included the subform’s level ID, the values list field’s field ID, the values list value ID of the “Yes” selection, and the field IDs of all the DisplayField requested in the results. Acquiring all these IDs through the API would take several requests, and the IDs can vary between development, test and production environments. Finally, the result would be returned in XML format which contains more IDs, requiring additional API calls to translate into text values.
   
   Here’s what the search looks like in Estrelica.Core.

The subform was identified by its alias, not the level ID, which is more accessible and unlikely to differ between environments. The alias was used in this example, but it would be just as simple to use any other identifier (name, GUID, ID, etc.). Then the search XML was automatically built, applying all DisplayFields within the level, and a filter condition which uses the value list value text of “Yes” instead of the underlying ID. The result of this search request is a collection of records serialized into the IArcherContentAccess type, which makes working with the search results simple.

2. Now that the Questionnaire Comments records have been returned from the search, specific data points should be gathered to be used as input for the Finding which is to be created. Those data points are located on both the subform record as well as the parent (questionnaire) record. The subform contains a field which contains the field ID of the field on the parent questionnaire which the subform originates from. The Finding should contain the value of that field as well as the question itself. The question field could be one of many different field types, so the field type will need to be identified, and the answer value parsed accordingly.  

This type of scenario is where development efforts are difficult to accurately predict. While the business requirements seem clear to a business user or project manager, the path to accomplishing those requirements is clouded for the development and configuration teams. Which API calls are used to obtain the question’s text value? What if one subform record is based on a question from questionnaire A and the next subform record is based on questionnaire B? Even with the field ID of the parent questionnaire’s comment, how can the parent questionnaire record and its content ID be identified? 

This code will gather all the values described above, regardless of what questionnaire the comment originates from. Whether that question was answered in the form of a radio button, check box or a text box, the answer value will be captured into the same string. While the Archer API documentation does not disclose how the question’s text value can be obtained the developer is able to locate it quickly by examining the questionnaireQuestionField object in their IDE and see that the question’s text is stored in the AdvancedDisplayOption.DisplayText property.

Since the code is more concise, it is easier to document with comments and read. Removing the complexity of accessing Archer’s data leads to more accurate estimates for development effort and meeting more requirements in a given timeframe. Concise, well-documented code also means easier maintenance. Additional features or adjustments to the project after it goes live can be made efficiently.

3. Last, a Finding needs to be generated and the subform’s ‘flag’ should be set back to “No”. This code is added within the foreach loop we created in the previous step.

During the creation of the new Finding record, any validation rules applied at the field level will be considered. If any of those validation rules are not met at the time the creation of the record is executed, a clear error message will be returned which can be logged with ease. Instead of logs failing to capture valuable pieces of error messages and those messages requiring technical expertise to decipher, with Estrelica.Core coherent messages are presented which different types of users can understand. This transparency leads to less time spent debugging and accelerated remediation.   

Conclusion