It’s also likely that for batch operations to work well for many different kinds of applications, the server may support multiple policies that specify for a given batch operation the atomicity, consistency, and isolation guarantees. One policy might ensure that the entire batch either completely succeeds only when there are no revision conflicts, otherwise it completely fails. Another policy might be eventually-consistent in the sense that the changes in every batch operations will eventually be applied, though this may require the server to have application-specific conflict resolution logic. And there are policies that are somewhere in-between. For example, imagine a server that supports “public” collections whose entities can be read/updated by any user, and “private” collections that expose only the entities that are readable and editable by that user. The likelihood of a concurrent update conflict on a private entity is quite small, since it’s possible only when different changes made on different devices are submitted at exactly the same time. On the other hand, the likelihood of a concurrent update conflict on a public entity is much higher. The server may allow updates to both public and private entities within a single batch operation, and a save policy that might update all private entities atomically (they all succeed or they all fail) while updates to *each* public entity is atomic (some might succeed while others might fail).