nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

BBP/SKYAPI: Matching gift batch record with approved gift record

Marlin Integrations

We are trying to patch the receipt number for gifts that have been created as part of an approved gift batch. The issue is that the gift ID we receive when creating a gift batch doesn't match the gift ID of a gift created after approving the batch. Example: We created a batch with a single gift and received gift ID 142892. We are sure this was the correct ID as we could see it on the batch gift detail page. Then we approved the batch and checked the gift page (via constituent profile page) - the ID of the gift is 149588.

Is there any way how we can pair/match these two types of gift records? (gift within a batch and standard/approved gift).

We tried to set the lookup_id for a gift however that's being ignored while creating a batch gift record. Even though we've passed "av_web_1000" as the gift lookup_id we received response: "lookup_id":"7fef258c-cac8-4603-972e-f347b91c35e0"

Any advice will be highly appreciated.

Find more posts tagged with

Comments

Qgiv Product

@Marlin Integrations we're experiencing this same issue, our lookup_id we're passing looks somewhat like: gift-481893-339290-1667236148 , but ends up getting created as 20bab421-de73-4357-b49f-3d40b2f3d455

Were you able to come to any sort of resolution here?

Qgiv Product

Follow-up, and even stranger; when running a direct gift query on the gift id itself, the lookup_id returned is different from both the value returned back from the batch during export, and the value we tried to set it to.

In the example above, where we sent gift-481893-339290-1667236148 and received 20bab421-de73-4357-b49f-3d40b2f3d455 , the result of querying the record directly is 241356

(Raiser's Edge NXT playground/sandbox environment, for gift record 257243, querying

)

Anthony Gallo

There looks to be 2 questions in here.

We do not currently have a mechanism to map batch gifts to the created gift withing the API or the UI. We also do not track the import ID so that method would not work currently as well. This would be a feature add that we would want to track in our idea portal to properly gauge the need.
The lookup ID issue does sound like a bug, and we can probably take a closer look at that. We would want you to file a bug with our customer support team so they can get all the needed details and send it to us that way.

Qgiv Product

@Anthony Gallo & @Marlin Integrations ; got it. I took a quick look at the aha.io requests, and I think

is related to point #1 that Anthony mentioned here. I voted on it and added a comment with more description for the specific case mentioned here.

For #2 , I'm happy to submit a request to customer support as a bug. To do so, what is the proper avenue we should take for that? (reach out via email somewhere?)

Anthony Gallo

@Qgiv Product
Just to follow up and close the loop here. This is currently a full gap that we have in our gift processing. The lookup ID will not be able to be submitted to batch and then flow thru to the record and we have a few reasons why. We would need to look at this down the road when we get into some more gift batch work to see what we can do better here.

These are the reasons why we currently cannot pass thru the lookup ID value via batch. We have no plans to make any changes here in the near term.

The lookup ID value HAS to be unique for each gift record.
If the gift is added to the batch, we can check that the value is unique against other batch gift records, but not other gift records.
There is no way to edit that field on a batch gift in the UI. Therefore, the batch gift could be stuck in an un-committable state.
For example...
1. Let's say a user adds a batch gift with a lookup ID value of 123. Currently, there are no records in either the BatchGift table nor the GIFT table with that lookup ID.
2. Then, a user adds a gift record in RE7, web view, or via the API with the lookup ID 123. This is allowable because only a batch gift record exists with this lookup ID, not a gift record.
3. If we tried to persist the lookup ID value from a batch gift to committed gift upon approval, the batch gift from 4a would not be able to be added and batch approval would fail. Why? Because the gift record from 4b already has that lookup ID.
4. And since the lookup ID on the batch gift record is uneditable, it will never be able to be committed without the intervention of an engineer.

Qgiv Product

@Anthony Gallo
Got it, thank you for the explanation here! This makes sense from a technical level, I definitely see the potential complexities with maintaining a unique lookup_id as a record moves from batched gift to approved gift.

I will note that this likely does mean that it's not really possible to connect an exported record from a service to the final gift record in Raiser's Edge NXT if it was sent through a batch, unless of course a custom field category were commandeered for this purpose (and since there's some complexities in mapping to gift custom fields that require NXT Data Integration endpoints, this would be infeasible for users who activate who do not have the “Environmental Admin” privilege). I think this is connected to what you mentioned on your earlier reply where this would likely be a feature add that would need to be tracked in the Ideas portal; I can investigate adding a listing there for this. (EDIT: saw on an earlier comment that API-I-305 seems to be related; instead of creating a new listing I'll just add an update comment on that existing idea)

In the meantime, it does look like the documentation for Gift (Batch) does describe “lookup_id” as a field that can be modified (

) , would it be possible to modify that documentation to note that the lookup_id is not preserved when adding a gift via the batch endpoint logic?

Anthony Gallo

@Qgiv Product
we have a task to update the documentation in the next couple of days. We will try to make everything as clear as possible here.