Finance | Project Operations, Human Resources, ...

Why is it bad to put RecId in a business event?

(5) Share

Report

Posted on by hca

158

Hi Community,

I've been working with Business Events and only recently noticed a note in the Microsoft Business Event developer documentation.

It says: "RecId values should not be part of a business event's payload. Use the alternate key (AK) instead."

Here is a link to the docs: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/business-events/business-events-dev-doc

Here is the note:

I've searched around a bit and I can't find any obvious reason why it's bad. The only thing I can think of is security, but I don't know how relevant that is.

What could be the reason we should avoid this? How should we go about getting an alternate key for a Customer (CustTable) for instance?

Thanks!

Categories:

Dynamics 365 Finance

I have the same question (0)

All responses (5)

Answers (0)

Adis 6,069 Super User 2025 Season 2 on at

Like (2)

Report

Hi,

Unfortunatly, I cant answer you the main question. However, regarding the CustTable, I would say the account number and the dataAreaID

By the way, we created a BE when a customerRecord is changed. This is how it looks.

Kind regards, Adis

If this helped, please mark it as "Verified" for others facing the same issue

Keep in mind that it is possible to mark more than one answer as verified

Was this reply helpful? Yes No
hca 158 on at

Like (0)

Report

Ok, so are you saying an alternate key is basically something we create on our own when we send the event? The use case for the business event is similar to yours, and in our case we assume that the RecId is unique for each customer. That's good enough for us, we don't need an alternate key.

I've had doubts if it is good practice to create a business event if a customer changes. I think it may conflict with the intent as described by Microsoft: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/business-events/business-events-dev-doc#intent. It sounds to me like more of a data export scenario than a business action, but it's debatable.

Was this reply helpful? Yes No
Suggested answer

Anton Venter 20,346 Super User 2025 Season 2 on at

Like (1)

Report

Hi,

RecIDs are internal system record identifiers and may differ when updating across environments. In fact, if the same data was added in two different environments, the RecIDs will be different. That's why it's better to use the natural key of the data rather than the RecID.

Was this reply helpful? Yes No
André Arnaud de Cal... 301,170 Super User 2025 Season 2 on at

Like (2)

Report

Hi hca,

As Anton mentioned, RecIds are internal references. In case you have the payload and want to retrieve more information about e.g. the customer or related sales orders, you must use the natural values to be able to filter for data in related data entities. RecIds are then not supported.

You were thinking of a possible security reason, but that is not the case. Can you indicate why you prefer RecIds in the payload and what actions you perform using those RecIds after a business event is sent out?

Was this reply helpful? Yes No
hca 158 on at

Like (0)

Report

@Anton Venter

That's fair, but we probably don't want to use the same RecId if that was the case.

@André Arnaud de Calavon

It's not that we want to use RecId, we just did because it seemed fine for our needs. After reading the note from Microsoft, I just want to ensure that we are not doing something horribly wrong. RecId seems like the "most unique" identifier. We use it to identify the customer in an external system. In this particular case we don't need to request additional data. The value in "AccountNum" field that @Adis suggested is also used in other entities even though there is no relation between the records. But if we used something "customer_BRMF-000001" that would be unique. But it's not something we would like to change anymore at this point.

Was this reply helpful? Yes No