Metadata changes in live projects

Best practice when updating or adding metadata (fields, entities) on backend server

In case a change is made on the backend server, e.g. changing option set values, Woodford must be restarted so that it can load the latest changes in metadata. Then you need to republish all projects to apply these changes to them. If a field is added to the backend, you also need to enable it in the project and place it into view or form.

Security role permission change

You need to perform force full sync to apply these changes to the local offline database. Otherwise, records that were synchronized earlier, and might be excluded with the new permissions, can remain in the local offline database.

Best practice when disabling fields

When a field that is used somewhere in the application is disabled, Mobile CRM application can crash when the user tries to access a view or form where this field is used. To avoid this situation, you should keep in mind these steps:

When you want to disable the field that is enabled in the entity, first remove the reference of this field from each view, form, or chart, and also from other entity views where it is used. You can use the Check Usage screen > Used Fields tab to see where a field is used.

• For views, edit the view, click Select Fields, and disable the field from the view.
• The same applies to charts. Use Select Fields to remove the field from the view.
• For forms, you just need to delete the field from it.

Now the field can be disabled and it will no longer be used in Mobile CRM application. Any change in fields (enabling/disabling a field) causes a full sync for this entity.

A special case is when you want to remove a field from the CRM server.

• If this field is enabled and used on the Mobile CRM application, first perform the steps above.
• Let users to synchronize the app, but instruct them not to make any changes to data.
• After they all synchronize, remove the field, publish the project, and synchronize again.

This is the only way to prevent problems where users make changes to a field that is going to be removed. A problem that can occur is that server reports an error when a Mobile CRM app attempts to update/fill in a field that no longer exists on the CRM server.

Removing field/option from CRM server

When you remove a field, an option from an option set, or an entity from the CRM, you first need to let your users synchronize the changed data, and then remove all references of the field from forms and views. Then you can disable the field in the project and the field can be removed from the CRM. Otherwise, users that have the field filled in, will not be able to synchronize the changes.

When this situation happens (you remove a field or option from option set) and users are not able to sync, as value in their record does not exist on the CRM server anymore, that option needs to be added back to the CRM server, let user(s) synchronize and then continue as above.

Alternatively, users must delete their changes/data by selecting the Advanced > Delete Data option in the app's Setup. Of course, they lose any unsynchronized changes.

Server deletes – bulk deletes

If you do delete records on the CRM server, you may have noticed that when you do so after synchronization, deleted records are still present on the Resco Mobile CRM application in offline mode. This is because of how incremental synchronization works. How to avoid and fix this situation?

You need to enable the delete plugin in Woodford for those entities, on which you perform deletions. After enabling this you need to perform a full sync on devices, to get rid of the deleted records from the local database. From then on, deleted records will also be deleted from the device during incremental sync.

But be careful if you are performing a lot of deletions – e.g. one of our customers deleted all the appointments and created them again with, changed the date each night – as it can slow down the synchronization. We have made several improvements in this area, performing entity full sync if we determine that checking for deletions will take more time than a full sync. But still, it is better to use a deactivation of records instead of deletion. Deactivation is a change and thus, the incremental synchronization will handle them. Then, after all users synchronize, you can bulk delete deactivated records without any issue and set the sync filter not to keep deactivated records in the local database.