Hello,
We are running an integration process that continuously updates records while users may still be accessing them. Is there any way to capture if someone has a record open and is editing it? I see system fields in my table for NATE disposition and NATE container?? But there is nothing in them? Are those fields meant to hold pending information? I could use them to “kill” my integration before it runs when someone is editing the record. This issue has been causing lost work for our customers.
Thanks!
Unfortunately there is not a system way to capture if someone has a record open and is editing it.
Those NATE disposition and NATE container fields will always be empty from the perspective of your integration process. When it fetches, it fetches the Live version of the record to make its edits, never the in-progress record that another user is working on. We haven’t exposed any means of fetching another user’s in-progress work.
If this is causing lost work for customers, please consider submitting an enhancement request with support.
–
I have seen some partners resolve similar issues using the Fetch and Lock action in Logic Blocks. If your customers can interact with an app built over a Work Table, then their Save can be controlled via Action Block. During that Action Block, you can Fetch and Lock the original record from the real table to make their update, which will guarantee that an integration can’t run at the same time and take precedence.
This works best if your customer only needs to work with a handful of fields from the app, and ideally if those fields are different fields than the integration modifies. Since the user will be working with a Work Table, their changes will need to be copied field-by-field into the original table when they’re done. If the integration ran in the background and replaced some of those fields, then the user’s changes will overwrite the integration’s changes when they save.
This works for some use cases but not all. I’m interested to see if anyone else has any ideas here.
2 Likes
A small nuance to this message:
If the integration ran in the background and replaced some of those fields, then the user’s changes will overwrite the integration’s changes when they save.
This is true if the user got a fresh version of the record after the integration ran.
If the changes happen simultaneously to the same version of the record, our version control mechanism will kick in (driven off the last modified date field) and whoever edited the record second will get a message stating that the record had already been modified by another user and that they’ll need to refresh to receive the latest changes before making any edits.
–
But I agree with Brendan - there’s not a way to determine “who else might be editing this record right now?” and drive behavior off of it.
2 Likes