# Notification Preferences A dedicated "Notification Preferences" screen is a critical component of a trustworthy application. It provides users with a central place to control how and when they receive communications from you. Giving users granular control is the best way to prevent them from disabling *all* notifications at the OS level—an action that is often difficult to reverse. This screen is where you empower your users, respect their choices, and give them a clear path to re-engage with recommendations they may have previously disabled. *** ## **Key Components of a Notification Preferences Screen** Your preferences screen should be simple, clear, and organized into logical sections. We recommend including the following components. ### **Master Push Notification Control** This section should transparently reflect the app's overall permission status at the operating system level. **If Permissions are Enabled** * Display a clear status indicator: Push Notifications: Enabled * Provide a button or link that deep-links the user directly to your app's notification settings within their phone's OS. This gives them a quick path to the system-level controls if they need them. **If Permissions are Disabled**: * Display a clear status indicator: Push Notifications: Disabled * Provide a brief, helpful message explaining the value of notifications (e.g., "You are missing out on important alerts about your energy usage and potential savings."). * Provide a single, prominent button like "Enable in Settings" that deep-links the user directly to your app's notification settings in the phone's OS. This is the only way to allow a user to re-opt-in after denying system-level permission. ### Category-Level Toggles This is the most important part of the screen for long-term engagement. It allows users to opt-out of *some* recommendations instead of *all* of them. These categories should directly correspond to the types of rules you have configured (e.g., using [Tags](/platform-manual/rules/rule-configurator/tags.md)). * Functionality: Each category should have a simple on/off toggle. *** ## **Best Practices for Design and UX** **Use Plain Language** Avoid technical jargon. "Cost-Saving Tips" is much clearer to a user than "Rule Category 7B." **Make it Easy to Find** This screen should be accessible from your app's main "Settings" or "Profile" menu. As recommended, you should also place a direct link (e.g., a settings icon) to this page from the Notification Center. **Provide Immediate Feedback** When a user flips a toggle, the setting should be saved immediately. There is no need for a "Save" button on this type of screen. **Respect User Choices** This is paramount. If a user turns a category off, your system must honor that choice without exception. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://doc.moost.io/best-practices/user-experience/notification-preferences.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.