Skip to main content
Recent results and favorites store result references rather than complete model payloads. Opening them resolves the result again under the current panel, user, guard, tenant and locale. Missing or inaccessible records are omitted.

Configure the visible collections

The default store is session-backed. History is not a permanent activity audit, and a favorite is not a grant of record access.

Disable a collection

The corresponding saved preference is locked. Hiding a control does not require changing your model or resource policies.

Persist across sessions

Run the package migrations before enabling the database store:
The store uses the package’s flex_theme_search_collections table and bounded JSON references. You can choose another Laravel database connection with new DatabaseSearchCollectionStore(connection: 'search'); that connection must have the required table. Database mutations use a scoped cache lock. On multiple application nodes, configure a shared lock-capable cache store through FLEX_THEME_SETTINGS_CACHE_STORE, for example Redis, so concurrent favorite changes share the same lock backend.

Implement a store

The supplied scope is opaque. Preserve it as an isolation boundary; never collapse all users or tenants into one key. Store only bounded references and honor the requested limit. For concurrent writes, implement AtomicSearchCollectionStore as well:
Run the callback while the scope/collection is locked. It returns [new references, operation result]; persist the bounded references atomically and return the operation result. collections(null) restores the default session store.

Category-level favorites

The category adapter supports a per-result rule:
This is presentation control in addition to actual data authorization. Do not infer a security policy from a URL prefix in a real application when a model policy or explicit result property is available.