How to Store User Preferences Across Sessions and Devices

What are user preferences?

User preferences are choices that shape a person's experience in your application: a display language, a dashboard layout, saved filters, or a preferred report format. Remembering these choices lets a returning customer continue without configuring the same screen again.

Preferences describe how a customer wants a product to behave. Progress records describe what they have completed, while drafts contain unfinished work. These can share a storage service, but your application should distinguish them so that changing a display setting does not accidentally replace a draft.

For a startup, begin with one useful choice. A reporting tool might remember a date range; a reading app might remember text size. Persist information because it improves the customer's task. The data minimization guide covers deciding which information is necessary.

Browser storage or account storage: which should you use?

The deciding question is where the preference should follow the customer. A temporary choice in one tab has different requirements from a setting that must return after login on another device.

MDN documents the scope of session storage and the longer browser-session persistence of local storage. Browser persistence alone does not mean the data belongs to a verified account. On a shared computer, account-specific settings must not be shown to the next person merely because a local copy exists.

For a preference that should follow a signed-in customer, use the saved account record as the source your app loads. If you also keep a local copy for convenience, define when it is refreshed and cleared. Do not silently replace a newer account setting with an older browser copy.

An example: the same dashboard after a new login

Imagine a small business owner using a reporting app. They choose a compact dashboard, select a monthly reporting period, and save a filter for their open projects. This is an illustrative application built around saved settings, not a ready-made reporting product supplied by Gammal Tech.

1. First visit: the owner signs in, chooses the settings, and receives confirmation that the app saved them.
2. Later visit: they sign in again. The app retrieves the choices saved for that account and project, then applies them to the dashboard.
3. Another device: after signing into the same account, they can retrieve the saved settings there too.

The session credential can change while the stored choices remain associated with the account. Your app should not create another preference record simply because the current token differs. The session tokens and saved data guide explains this distinction.

Only successfully saved information can be restored this way. Text left in a form without being saved is not automatically backed up. Make the difference between an unsaved change and a completed save visible to the customer.

Restore saved preferences before saving defaults

A common application mistake is to open a page with default settings and immediately save those defaults before the existing account data has loaded. The customer then appears to have lost their choices even though the storage service kept them between visits.

Plan a clear sequence: confirm the current session, retrieve its saved project data, apply the available settings, and then enable changes. Treat a successful first visit with no saved preferences differently from a failed request. A connection problem is not evidence that the customer has no saved data.

• Loading: show that saved settings are being retrieved; avoid a competing automatic save.
• Ready: apply saved values and use sensible defaults only for settings that are absent.
• Saving: show progress and confirm completion only after the save succeeds.
• Unable to load or save: keep the message understandable and preserve the customer's current choices where possible.

When a customer signs out, clear the private information displayed by your app. If another person then signs in on the same device, a response from the earlier session must not overwrite that person's screen. These are application responsibilities to implement and test.

Understand Gammal Tech's storage limits and update behavior

The Gammal Tech integration reference documents saved user data that persists across visits and devices. Access requires sign-in, and the maximum stored size is 1 MB per user. This suits compact preferences, bookmarks, progress, and small drafts. It is not a large-file archive.

Updates merge at the top level. Changing a separate theme field keeps an existing bookmarks field when that field is not included in the update. However, sending a setting whose value is a nested object replaces that whole nested object. If language and dashboard layout are grouped together, sending only the language inside that group can replace the previously saved layout in the group.

Design the saved structure around the choices your app updates together. The reference also reserves field names beginning with _gt_ for the service. For exact integration methods and current limits, use the reference rather than inferring behavior from the visible settings screen.

Persistent storage does not by itself promise live synchronization or automatic resolution when two devices save conflicting edits. Plan that experience separately if your product needs it. User data storage is documented as free within the size limit; login-code charges are separate. See the account features and pricing guide for the wider setup.

Keep preferences separate from identity and permissions

Your project can retrieve only customer data it has stored itself. Gammal Tech does not supply additional profile or identity information. Developers cannot request the customer's phone number, email address, legal name, national ID, or other identity details from the underlying Gammal Tech account. If your project never saved a language preference, for example, it must use a default or let the customer choose; it cannot ask Gammal Tech to fill that field from an account profile.

Every Gammal Tech account requires national ID verification, and each person can have only one account. Gammal Tech handles that identity check without exposing its identity details to your project. Your app can restore the preferences it saved for the returning verified account without receiving the person's identity details.

Editable preferences should not decide whether someone is an administrator, owns another customer's records, or has paid for a restricted feature. Those decisions require appropriate authoritative checks. A display choice and an access permission have different jobs.

Keep session tokens out of preference fields, analytics events, and customer-facing examples. A token remains a sensitive credential even when login does not reveal contact details. Read the privacy-preserving login guide for the account-information boundary.

Check the complete returning-customer experience

Use ordinary test preferences and check the journey before offering it to customers:

• Save a choice, sign out, and sign back in to the same project. Confirm that the saved choice returns.
• Sign in on another device and retrieve the same saved settings.
• Change one field and confirm that unrelated stored fields remain intact.
• Check a failed data load: the app must not save defaults over an account it could not read.
• After one person signs out, have another person sign in with their own verified account on the same browser. Confirm that the first person's settings are no longer displayed.

Gammal Tech documents per-tab sessions, with another sign-in for a fresh tab or reopened browser. Explain that experience wherever customers expect to resume work: signing in again is compatible with keeping their previously saved preferences.

Common questions