Access Recruitment CRM now integrates with the Access Evo (AI) Meeting Assistant, enabling interview data captured during applicant meetings to be automatically received and optionally stored in the CRM.

When the AI Assistant completes a applicant interview, the meeting data is securely transmitted to ARCRM and processed in the background. Records are inserted into the Evo Meeting Assistant Results screen within minutes of the interview completing, without any manual intervention required from the recruiter.

The following applicant information is captured from each interview and made available on the Results screen: Name, Email, Desired Job Title, Current and Minimum Salary, Availability, Available Date, and an Interview Summary.

This removes the need to manually capture meaningful and structured notes during meetings, preventing loss of context, improving captured details and the time spent documenting the output.

A new Tools ; EVO Meeting Assistant ; Results option has been added to the left-hand navigation menu giving users quick access to the new screen.

The Evo Meeting Assistant ; Results screen includes a fully interactive Applicant Review Queue - a searchable, paginated list of applicants extracted from your meeting recording. This is the entry point for reviewing and correcting applicant data before it is committed to the CRM.

When you open the Evo Meeting Assistant results page (via Tools ; Evo Meeting Assistant ; Results), a list of applicants awaiting review is displayed in a panel on the left-hand side of the screen. Each card shows the applicant's name and desired job title. The first applicant in the list is automatically selected, with their details loaded in the detail panel on the right.

The list defaults to showing applicants assigned to you (Own). You can switch the ownership filter dropdown to Group or All to broaden the list. Changing the filter immediately re-queries the data set, and all active search terms are applied at the same time.

A search box at the top of the panel lets you filter by applicant name or desired job title. The search retrieves matched records after you stop typing to avoid unnecessary data fetch requests, and pagination resets to page 1 whenever the search term changes. Clearing the search restores the full list for your current filter.

Click any applicant card to select it. The selected card is highlighted and the detail panel updates to show that applicant's information. Only one applicant can be selected at a time.

If you make edits to an applicant without saving, a small orange dot appears on their card. This dot persists if you attempt to navigate away and return. If you try to switch to a different applicant while unsaved changes exist, a dialog warns you that switching will discard your edits. You can cancel to stay on the current applicant or choose to discard your changes and move on.

The footer displays the total record count, current page, and total pages (e.g. "Page 2 of 5"). Previous and Next buttons allow you to move between pages. The number of cards displayed per page adjusts automatically if you resize your browser window and will never drop below one card.

If your search or filter returns no results, the list displays "No applicants match your search." with a prompt to adjust your filters, and the footer shows "0 records." If there are genuinely no applicants to review (no search or filter applied), the list shows "No applicants to review."

The list panel can be collapsed using the << button alongside the search bar, giving more screen space to the detail panel. Click >> on the collapsed strip to restore it. Collapsing and expanding the panel does not affect the currently selected applicant and does not trigger a data re-fetch.

The Process All Applicants button is enabled whenever at least one applicant is present in the filtered list, and disabled when the count is zero or when a save/process operation is already in progress.

A Details tab is available in right-hand details panel, giving users a fully editable form to review, correct, and enrich the data the AI has extracted for each applicant before it is written to the CRM.

When you select an applicant from the review queue, the right-hand panel refreshes. The Details tab will be active by default. The form displays all extracted fields - Name, Surname, Email, Desired Job Title, Current Basic Salary, Min Basic Salary, and Available Date - alongside dropdowns for Currency, Rate Unit, and Availability, and checkbox lists for Sectors and Employment Types.

All values are pre-populated from the AI extraction. Fields with no extracted value are shown as empty inputs. Sector checkboxes default to your configured default sectors, and Employment Type checkboxes reflect the applicant's extracted preferences.

Every change you make is tracked locally and reflected immediately in the UI. An orange unsaved dot appears on the applicant's card in the list panel to confirm that edits are pending. No data is sent to the server when the individual edits are carried out - all changes are only submitted explicitly on save.

Current Basic Salary and Min Basic Salary accept numeric input only. Values are stored as a float; clearing a field stores it as 0.00.

Locally edited values are preserved if you switch to the Interview Summary tab and return - the form does not reset to server values because of a tab switch.

If you navigate to a different applicant with unsaved edits, a discard prompt is shown. Confirming the prompt reverts all local edits for that applicant to the last saved values and removes the orange unsaved dot.

All dropdown and checkbox options are populated from your CRM configuration - Currency, Rate Unit, Availability, Sectors, and Employment Types are each drawn from their respective Options > Manager lookups.

Name, Surname, and at least one Sector are required before saving or processing an applicant. If any of these are missing when you click Save or Process Applicant:

Validation errors clear field-by-field as you correct them - there is no need to re-submit the form to remove an individual error.

An Interview Summary tab is available to the right of the Details tab. When a meeting recording is processed, the AI-extracted summary interview details for the applicant is surfaced here, ready for review and refinement before it is committed to the CRM.

When you select an applicant from the review queue and click the Interview Summary tab, the AI-extracted summary for that applicant is displayed in an editable text area. The full text is scrollable within the panel, and any formatting from the original extraction - such as line breaks or bullet points - is preserved. Where no summary has been extracted for an applicant, the field displays placeholder text to indicate it is empty and ready for manual input. You can click straight into it and begin typing.

Any changes you make to the summary are tracked immediately. The orange unsaved dot appears on the applicant's card and the Save button in the header becomes active - just as it does when you edit fields on the Details tab. Nothing is sent to the server until you explicitly save.

If you switch between the Interview Summary and Details tabs, your edits and the current size of the text area are preserved exactly as you left them. If you navigate away to a different applicant and confirm the discard prompt, the summary reverts to the last value held by the server.

A resize handle at the bottom-right corner of the text area lets you drag the panel taller or shorter to suit the amount of content you are working with. The panel will not reduce below a minimum height to ensure the content remains readable.

Consultants can review and refine AI-extracted interview notes directly within the Meeting Assistant workflow, without leaving the screen or switching context. Edits are tracked alongside any other applicant changes, and nothing is written back to the CRM until the consultant is ready to save.

A duplicate detection panel in the right-hand column of the Details tab provides consultants with full visibility and control over how candidate records are handled when the AI identifies a potential match against an existing CRM record.

When you select an applicant from the review queue, the right-hand column of the Details tab shows the outcome of a server-side duplicate check carried out during meeting extraction.

Where no match was detected, a green badge reading "No Duplicate Found in Sectors Logged Into" is displayed. No further action is required before processing the applicant.

Where a match has been detected, a red badge reading "Duplicate Found in Sectors Logged Into" is displayed. Below it, the following controls become active:

Switching the dropdown to Create New Applicant immediately hides the Existing Applicant field, View and Search buttons, and Fields to Update checklist. The applicant can be processed without any field selection. This change is tracked as an unsaved edit - the orange dot appears on the applicant's list card.

When Update Existing Applicant is selected, at least one field must be ticked before the applicant can be processed. Attempting to process with no fields selected shows a toast error ("Please select at least one field to update") and highlights the checklist border in red. Each checkbox change is tracked locally; no API call is made until you explicitly process or save.

The green or red badge is read-only. The duplicate flag is determined server-side during extraction and cannot be toggled or overridden directly - only the action to be taken in response to it can be changed.

Clicking the Search button opens the Duplicate Lookup Dialog, allowing you to manually select a different CRM record as the duplicate target.

The dialog header displays "Select Duplicate Applicant" alongside the current applicant's full name. A search input allows you to filter results by name - results update after a short delay as you type, and clearing the field returns the full unfiltered list.

Results are displayed in a paginated table showing up to 20 records per page, with First, Previous, Next, and Last navigation controls and a record count in the footer. Clicking a row highlights it and enables the Select button. Selecting a record closes the dialog and updates the Existing Applicant field with the chosen record's Filed As name and numeric ID, tracked as an unsaved edit.

Closing the dialog without selecting a record leaves the Existing Applicant field unchanged and introduces no unsaved changes. The dialog can be repositioned by clicking and dragging the header bar. It resets to its default centred position each time it is reopened.

The results screen includes a full commit layer for processing candidates into the CRM. Consultants can save individual applicant changes, process them into the CRM one at a time or in bulk, delete records they no longer need, and receive clear feedback at every step - including warnings when changes are unsaved and alerts when another user has modified a record at the same time.

A Save (💾) button in the app header becomes active whenever the currently selected applicant has unsaved local edits. Clicking it validates the record first - if required fields are missing (name, surname, or at least one sector), the failing fields are highlighted in red and a toast message identifies each issue, without making any API call. When validation passes, the changes are submitted, the unsaved orange dot is removed from the applicant's card, and a confirmation toast is shown.

The Process Applicant button submits the selected candidate directly into the CRM. The system always saves the applicant's current data first (to ensure any default-applied values continue to persist), then calls the process API. On success, the applicant is removed from the list, and the next candidate is automatically selected. If no candidates remain, the detail panel shows an empty state.

The Process All Applicants button batch-processes the full list. The exact dialog shown depends on the state of the list:

During processing, a progress toast updates periodically to show how many records have been processed. On completion, a summary toast reports the overall outcome - with zero-value counts omitted from the message for clarity.

The Delete (🗑) button triggers a confirmation dialog naming the applicant before any action is taken. Confirming removes the applicant from the list, and the next candidate is automatically selected. The Delete button is disabled when no applicant is selected or when another operation is in progress.

If a consultant clicks a different applicant card while the current one has unsaved edits, an Unsaved Changes dialog is shown before the switch is made. Choosing to discard changes restores the original data for the current applicant and then loads the newly selected one. Clicking Cancel keeps the original applicant selected with all edits intact.

The system distinguishes between two server-side conflict conditions:

All action buttons (Settings, Save, Process Applicant, Delete) are disabled while any save or process operation is in progress. The Process Applicant button label changes to "Processing..." for the duration, and list panel cards are non-interactive until the operation completes.

Consultants can work through their meeting results confidently, knowing that no changes will be lost, and no applicant will be submitted prematurely. Clear inline validation, contextual dialogs, and concurrent conflict warnings remove ambiguity at every decision point - whether processing one record or fifty at once.

The results screen also includes a Settings dialog, giving recruitment consultants the ability to configure and persist their personal working preferences once - and have them applied automatically every time a new set of meeting results loads. This is the final story in the Evo Meeting Assistant Results MFE series, and one of the most impactful for day-to-day use: rather than manually setting sectors, duplicate actions, and fields to update on every applicant, a consultant can define their defaults upfront, and the system handles the rest.

A ⚙ Settings button sits in the app header throughout the Evo Meeting Assistant results screen. Clicking it opens the Settings dialog, which is modal - all other panels and controls are inactive while the dialog is open. The button is disabled during any active save or process operation, becoming available again once the operation completes.

The Settings dialog is divided into four sections:

Clicking Save closes the dialog and immediately applies changes to the current session. Changes to Default Sectors and Default Fields to Update propagate live to all applicants already loaded in the list - no page refresh required. A "Settings saved" toast confirms the change. The preferences are persisted to the API in the background and will be in place the next time you open the results screen.

A change to the Default Filter also refreshes the applicant list from page 1 using the new filter value.

If you close the dialog or click Cancel without saving, all in-dialog changes are discarded. No API call is made, and no applicant data is affected.

When the Evo Meeting Assistant results page loads, personal settings are fetched from the API before the applicant list is retrieved, so your defaults are in effect from the very first result. If the settings request fails, the MFE falls back to built-in defaults (Default Filter: All; all other settings: empty) and continues to load normally.

Consultants who regularly process meeting recordings no longer need to configure sectors, duplicate actions, or update fields on every applicant manually. Preferences are set once, applied automatically, and updated live - reducing friction in what is designed to be a fast-moving workflow.