Add an option to make it an exception to have multiple matches above the auto-match threshold

Currently if there are multiple matches above the threshold BVDL will automatically pick one as the match and continue on. This is not always desired and can complicate duplicate management.

We have several imports that we want to be update only. A.k.a if there is a match, then update, otherwise ignore for all record types.

We built a SQL based orchestration to implement this but a checkbox would be better!

This would also helpful for testing imports without creating any new records.

To allow for the best review of possible matched records, we set our exact match threshold very high. This is particularly useful when we are bringing in records with limited contact info but there are other data points we can use to enhance a match (alumni status or class year, donor interests, etc).

However, what we are left with are many records with either a single possible match or multiple possible matches but one obvious choice based on an enhanced match score that was applied by a pre-processing dynamic operation. The only way to turn such choices into an Exact Match is to open the form for every record, select the match, and save it.

It would be great to have either a record op on the Constituent Matching Results or an action for a staged data instance that allows inputs of a new Exact Threshold that can be run…

Currently if you try typing a space into the "Replace with" field, it just becomes a null value/empty field again. Incidentally it seems you can't even get around this using the =RegexReplace function because even inserting " " does not appear to work and replaces with a null value instead.

It would be helpful to have a Parent and Detailed Outbound API call similar to the Inbound calls. We would use the Parent to get data from CRM and send one record at a time with the Detailed API call for updating constituents in our third-party application. Their API is limited to one update record at a time. This would ensure at data is correctly synced.

We just received an error

BVDL Business Process:DoGooder Integration - IN - Actions Taken, Did not finish, 18/08/2025 18/08/2025, Exceptions: 0;Error processing API mapping: Incoming value "PamHasn't these Mongrel Big Companies ripped enough from us Aussies?" in field "results.form_data.first_name" exceeds length of "FIRSTNAME".

Whilst I'll fix it this time by using a LUA expression to truncate the field value, I should now do this for all incoming fields in all of our API Jobs.

It'd be helpful to have an option at the Job level, to automatically truncate incoming text fields to their limit to avoid these sort of errors. What would be absolutely ideal would be to still be warned in some way, so that we knew it was happening, as otherwise it's possible that we wouldn't notice some misconfiguration.

We probably wouldn't turn this option on for file import Jobs as it'd probably be best to know and…

Now that we have the potentially very helpful Execute Data Form operation, it would be really useful to have a Search List operation, which would use any chosen BBCRM Search List, allowing population of the various fields much as Execute Data Form does, but specifying an output table and field, perhaps just limited to Constituent Placeholders or Extra Placeholders, but in any case, somewhere to store the resulting value, often a Record ID, which could then be used in other operations, such as an Execute Data Form operation. That way we could search for a record, then update it.

We often don't have the Record ID in input data but do have enough fields to uniquely identify a record to update, e.g., a Constituent Financial Institution.

Please consider adding the Number of records available for processing column so we can easily tell if older job runs truly have 0 records or they just haven't been processed yet. Also, please turn into a Listbuilder (with column filtering) so we can show/hide important fields. A new customizable column would be helpful so we could tie back an instance with an identifier from the source (i.e. ReportName, Date, ID, etc.)

When processing many exceptions, there's a lot of scrolling required, which makes the work much slower.

It would be very helpful if you rearrange the screen so that it is visible in one go on a reasonably normal monitor. At the moment, it scrolls off the bottom unless set to about an 80% zoom, which means either small text or a lot of mouse work scrolling up and down. There's a lot of unnecessary white space on the screen which could be removed. Perhaps there could there be a compact view option.

To cater for different organisation's requirements, perhaps it could be configurable which data fields and sections to display, so that we could hide many of the fields which we don't use, and the screen could then be smaller.