User Syncing Conflict

[Sarah_Keown]

Hi all,

I have recently deployed an app and am now in the process of carrying out training. Of course, with this comes new scenarios/issues needing to be adressed.

With the app there are mutliple users that will ultimately be logged in at the same time. Two users who were both working on the app, were syning the app simultaneously. One user had not made any changes but just clicked to sync and the other had just uploaded an image/updated a record. When they synced the user who uploaded new content had lost this upload.

Is this due to the timing of each sync i.e. the user for hadn’t made changes syncing first and that now being the updated/latest app version? Or is it the case where two users syncing at the same time causes conflict and nothing changes.

Very concerning either way if more than one user cannot sync changes. I assumed having an app that allowed for multiple users to be included would allow for syncing simultaneously?

Any thoughts on this let me know

These are my current sync settings.

[Steve]

Sarah_Keown:

One user had not made any changes but just clicked to sync and the other had just uploaded an image/updated a record. When they synced the user who uploaded new content had lost this upload.

I wouldn’t expect this to be a problem.

You say the user “lost this upload”. What about the update to the record?

Did you confirm that the upload did not arrive in your image store?

Did you confirm that the database/spreadsheet did not receive the updated data?

What data source are you using? Google Sheets? Office 365? A database?

[Sarah_Keown]

I did not get the chance to ask this as when I was told about the issue the user had already updated the record again and re-uploaded the images they needed to put in. So both the image store and spreadsheet have the data in it now anyway.

I am using Office 365 the spreadsheets are held on share point.

[WillowMobileSys]

@Sarah_Keown Don’t be discouraged!

I have supported the rollout of at least a couple dozen applications or major feature enhancements to existing apps. It is especially unnerving when it is brand new technology (not saying this is your case) because users are in an unfamiliar space and for many it is a challenge to break out of their comfort zone - obviously in our case that zone is the “old” software.

There is fear from your side that you will uncover some major flaw that will have the users running away!

Relax! You’ve done your testing you know the features and functions work. But no matter how much testing or debugging or tweaking we do, there will be issues. Its the nature of software.

I would venture a guess that probably 95% (or more) of the “issues” found in an initial rollout are user error OR processing simply done in a different way. The issue you described above sounds like user error. Did the user navigate back without saving?

There are some users, usually in every crowd, that just don’t like change and try extra hard to poke holes in the new app or find things that “worked better” in the old app. They will reluctantly fall in line and then complain all over agin when the next revision comes out - forgetting all about that old app!!

In the end, no software is perfect! Just look at all of the updates we each get and do nearly every day of just about every piece of software we use. Users are accustomed to it. And they will understand.

When an issue is reported, I probably don’t have to tell you, but simply work with the user to attempt to replicate the problem. This is where you’ll likely find they are trying to do something they can’t or found a different way than intended that needs a little development attention.

In the case of a verified issue, give them the ole “That’s a good find! We’ll get that updated in the next release!”.

[Cortex]

Hi,

Actually, no you can’t edit the same form, in the same time by multiple users.

It’s happened to my users a number of time.

It can happen too if a second user opens the updated form without syncing the app in between, he will open an old version of the form and erase the previous data by the change he will made. [the previously uploaded images will still remain on your cloud]

I don’t know how 365 works, but in my case, with google spreadsheet, we have access to all the inputs history. [easy to track and backup erased data]

To avoid this issue you have to train your users about the constraints and the limitations of your AppSheet application.

• Syncing the app before making any update to a form. [having an up to date data is really important when you have high-frequency changes in a table]
• Having a designated main user in the workers’ team usually avoid any wrong using the app

At first, i had a big table for all the inputs and a main big Form.

After a period, i splitted it into a main Form with attached subsidiary section Form linked by a réf column type, and a REF_ROWS(“Table_name”, “Réf”).

• Main Form
  • Id card of the site
  • Technical input
  • Image section
  • Etc…

Its visually more clear for the users, each section of the form can be filled by a different user at the same time and it seems sync changes are faster too.

Regards

[Egor_P]

Could you perhaps show on a screenshot how a form with main and subsidiary section looked like? I’m in a similar situation, but I do not understand how to link several sheets into 1 form.

Thanks!

[Cortex]

I will try to explain how now i manage my form :

Create a slice for every “Section” you want

1. In every slice, you need to add a common column [ usually your unique réf ]
   Let’s say you want to create an app for a building inspection, it will be the column having the Name Building

Create a view for every Section from the slice you created [ not mandatory, but i do like to edit the detail of the view by using quick edit column, like that no sync needed for the user to “transfer data”]

When all your views are finished, made them as a réf view

Now create an “App: go to another view within this app” action for every section view you just created :

For the target formula of the action :

CONCATENATE("#page=here the type of view you want to go, detail, form etc…&table= here the view name&row=", ENCODEURL([here your unique column]) )

Set them as Display prominently and choose an icon that reflects the section

Now you just need to add those actions in your main slice and those will be available in your main view.

You now have a kind of a main view with icon to go to every section,

With the same principle, you can create sub-section too

Don’t know if it’s clear,

[Egor_P]

Thanks for the explanation! I actually was not aware that slicing prevents overwriting all columns in the selected row. For now, my problem is resolved, but if data loss will keep happening, I will definitely use your solution!

[pravse]

To the original question — there is no way one user making an update can “lose” the update because another user just synced their data (wthout making any changes).

Whenever I hear about data loss like this, my first reaction is to ask — what is the row key? If the row key is the RowNumber, then that is the usual culprit (hint — never use RowNumber as the key).

Then if there are still unexplained issues, look at the audit log (Manage -> Monitor). It shows each change that came in. So even if the users have moved past this point, you can still go back in history and look at what happened, what was sent in by each user, etc).

[pravse]

@Jeremie makes a totally valid point that if two users are independently updating the very same row of the same sheet, then one’s changes can overwrite the other. In general, there is no good solution to this problem if multiple disconnected users (these are mobile apps running potentially disconnected on devices) want to update the very same row and not be blocked waiting on connectivity. By choosing to enable disconnected access as our design point, we have consciously given up on true transactional behavior for such cases.