Main difference between ‘write to entity’ and ‘write to records'

1) Yes and no. Activity chaining delays the UI refresh up to the end of the chain. It has no direct relationship to "refreshing record type data". And some UI components can be configured to refresh automatically using the refreshAfter parameter.

2) True

3) I would say, they are similar. Data store entities are a more direct connection to the database, and Records add another level of abstraction providing a bunch of extremely nice features. I try to shift my work to Records only.

One of the biggest differences is just the number of objects used. We created the Write Records node because that enables you to use a record type for all operations - if you use Write to DSE, you must create a CDT, Data Store, and Entity to perform the write.

There are also a couple of additional benefits to Write Records:

• You can write records and related records together, which makes it easy to update multiple tables at once
• You can use Write Records to also write record events, which can help you understand the key milestones in your application
• Write Records has an option to skip the node if an error occurs (while Write to DSE does not), which gives you more flexibility in writing data
• Write Records is more efficient at updating data - if certain fields are not included or not changed, Write Records ignores them, making updates faster and less likely to accidentally overwrite data

Like Stefan said - I generally recommend using Write Records over Write to DSE. It has a lot of benefits over Write to DSE, and we're also continuing to make updates to Write Records in the coming quarters!

Thanks for your reply

Thanks for your reply

Do not mark your gratitude as "Suggest as Answer".
If you find any answer helpful, mark it as "helpful".

1. Enable Activity Chaining: This option refreshes record data after an activity chain completes, and it works for both "write to entity" and "write to records."

2. Rule Input for Interface using CDT: You can use Custom Data Types (CDTs) to define input parameters for your interface. This applies to both "write to entity" and "write to records."

3. "Write to Entity" vs. "Write to Records":

   • "Write to Entity" is for saving data directly to a record entity.
   • "Write to Records" is another method for saving data and is considered the newer approach. Both have their use cases, and the choice depends on your specific needs. "Write to Records" is not necessarily a replacement for "Write to Entity" but offers different functionality and flexibility.

Which are all ways to handle record sync error during the process itself for write to record smart service.

If we configure write to record and if record sync fails with any reason after writing into source table then what could be the way to identify the issue in sync.

I can think of Record sync smart service by passing identifier after write to record to make sure it works and then notify the initiator for any error and to contact support team.

Any other suggestion apart from record sync error notification to Admin?

The smart service will handle that and fail in case of an error. Then the alert management of the process model kicks in.

We also recently introduced a feature for a "recovery sync": docs.appian.com/.../records-data-sync.html

This helps because if a write fails due to a sync issue, it will automatically retry a full sync and recover from the issue. It doesn't address all issues, but does account for a lot of intermittent issues!