The only thing I can think of is that the object has been opened by someone who did not have the read rights on the association. That association is then set to empty when opened because of the access rights. No problem untill the user commits that object again. Could a scenario like that have taken place?
Regards,
Ronald
Is there a reference selector in place with constraints on the selectable objects or a microflow source with some contraints, which would cause the assocation to be emptied when opening the page?
Thanks, Ronald. I didn’t know that could occur. However, all user roles with access to the object also have access to read/write on the association. So, that doesn’t seem like the cause here. If you have any other ideas, it would be greatly appreciated. This one has me stumped.
Is it possible that the parent object was auto-committed? I haven’t dealt with it much, but one of my team members has had issues with objects that were flagged as auto-committed getting removed when a session ends. Here’s some discussion on auto-commit:
Hi
We had the same issue on both deep associations as well as self associations on non-persistents. The issue was resolved by dropping non-persistents and replacing with persistents.
Are the associations being made in nested submicroflows? I’ve had data lost before that way. The solution was to return the changed objects at the end of the microflow.
Another thing to look at is if the associations are being set in an error handling path? They can be lost then.
I've seen this using one to one associations being set on both parent and child (had to be done in the past). Can't really explain why, but resolved it by removing the change on the child of the association. I know that's not the case for you, but wanted to share anyway (7.23.4)