review

Author: titerman

src/components/reusable/sharingaccesslevel.md

@@ -4,48 +4,54 @@ no_index: true
 
 <!--- sharingaccesslevel.md --->
 
-**Enabled (default)**
-
-Identified users (those with a [Customer User ID](identifying-users#setting-customer-user-id-on-configuration)) can share the same [access level](https://adapty.io/docs/access-level) provided by Adapty if their device is signed in to the same Apple/Google ID. This is useful when a user reinstalls the app and logs in with a different email — they’ll still have access to their previous purchase. With this option, multiple identified users can share the same access level.
+> Main article: [Sharing paid access between user accounts](sharing-paid-access-between-user-accounts)
 
-Even though the access level is shared, all past and future transactions are logged as events in the original Customer User ID to maintain consistent analytics and keep a complete transaction history — including trial periods, subscription purchases, renewals, and more, linked to the same profile.
+When a user makes a purchase, Adapty assigns a new [access level](access-level) to the active [customer profile](identifying-users).
 
-**Transfer access to new user**
+But the user's customer profile may change — if they reinstall the application, log into a new account, or purchase a new device. How does Adapty ensure that the buyer doesn't lose access to paid content? The **Sharing paid access between user accounts** setting determines Adapty's behavior.
 
-Identified users can keep accessing the [access level](access-level) provided by Adapty, even if they log in with a different [Customer User ID](identifying-users#setting-customer-user-id-on-configuration) or reinstall the app, as long as the device is signed in to the same Apple/Google ID.
+:::important
+If you need to test purchases on a sandbox account, change the setting for [sandbox accounts only](sharing-paid-access-between-user-accounts#sharing-paid-access-on-sandbox).
+:::
 
-Unlike the previous option, Adapty transfers the purchase between identified users. This ensures that the purchased content is available, but only one user can have access at a time. For example, if UserA buys a subscription and UserB logs in on the same device and restores transactions, UserB will gain access to the subscription, and it will be revoked from UserA.
+:::note
+Anonymous user profiles associated with the same store account *always* share their access level, regardless of this setting.
+:::
 
-If one of the users (either the new or the old one) is not identified, the access level will still be shared between those profiles in Adapty.
+**Enabled (default)**
 
-Although the access level is transferred, all past and future transactions are logged as events in the original Customer User ID to maintain consistent analytics and keep a complete transaction history — including trial periods, subscription purchases, renewals, and more, linked to the same profile.
+If the **Sharing paid access between user accounts** setting is on, new customer profiles associated with the same store account will *inherit* the access level of the original. This is the default behavior for Adapty apps.
 
-After switching to **Transfer access to new user**, access levels won’t be transferred between profiles immediately. The transfer process for each specific access level is triggered only when Adapty receives an event from the store, such as subscription renewal, restore, or when validating a transaction.
+* If a user logs into your app with a new set of credentials, they retain access to paid content.
+* If a user reinstalls your application after a factory reset, they retain access to paid content.
+* If a user installs the application on other devices with the same store account, the purchase is made available on all devices. Even if each instance of the application has its own customer profile.
 
-**Disabled**
+This behavior is best for common use cases and store compliance. Do not change it if your app does not have authentication capabilities, and only uses Adapty’s anonymous profiles.
 
-The first identified user profile to get an access level will retain it forever. This is the best option if your business logic requires that purchases be tied to a single Customer User ID.
+**Transfer access to new user**
 
-Note that access levels are still shared between anonymous users.
+If you select this setting, Adapty limits purchase access to 1 customer ID at a time. The device owner can reinstall the app, log in and out, but cannot access the same product from more than one customer ID simultaneously.
 
-You can "untie" a purchase by [deleting the owner’s user profile](ss-delete-profile). After deletion, the access level becomes available to the first user profile that claims it, whether anonymous or identified.
+For example, if a customer downloads your application on a second device, Adapty will transfer paid access privileges to the customer ID associated with the new device. The original device will lose access.
 
-Disabling sharing only affects new users. Subscriptions already shared between users will continue to be shared even after this option is disabled.
+If one of the customer profiles is *anonymous* (not associated with a specific customer ID), the two will continue to share the access level. This is necessary to prevent access loss in applications without mandatory authentication.
 
 :::warning
+When you disable from the default setting, Adapty does not immediately update the access levels of existing customer profiles.
 
-Apple and Google require in-app purchases to be shared or transferred between users because they rely on the Apple/Google ID to associate the purchase with. Without sharing, restoring purchases might not work upon subsequent reinstalls.
+The switch occurs when a user triggers a new store event: for example, renews the subscription, or restores their purchases.
+:::
+
+**Disabled**
 
-Disabling sharing may prevent users from regaining access after logging in.
+If you disable paid access sharing, Adapty ties the product to the active [customer ID](identifying-users#setting-customer-user-id-on-configuration) at the time of the purchase, and does not share these privileges with any other customer profiles. This policy allows for stict 1-to-1 product distribution, but demands mandatory in-app authenticaion.
 
-We recommend disabling sharing only if your users **are required to log in** before they make a purchase. Otherwise, an identified user could buy a subscription, log into another account, and lose access permanently.
-:::
+You need to implement your own authentication logic to make sure that users retain access to their purchases. Select this setting if your app requires customers to create an account before completing a transaction, with strict rules that tie purchases to a single user entity.
 
-### Which setting should I choose?
+:::warning
+If you disable paid access sharing, some users may not be able to restore their purchases.
+
+If your application does not guarantee that the user retains access to their purchases, it may fail the mandatory store review.
+:::
 
-| My app...                                                    | Option to choose                                             |
-| ------------------------------------------------------------ | ------------------------------------------------------------ |
-| Does not have a login system and only uses Adapty’s anonymous profile IDs. | Use the default option, as access levels are always shared between anonymous profile IDs for all three options. |
-| Has an optional login system and allows customers to make purchases before creating an account. | Choose **Transfer access to new user** to ensure that customers who purchase without an account can still restore their transactions later. |
-| Requires customers to create an account before purchasing but allows purchases to be linked to multiple Customer User IDs. | Choose **Transfer access to new user** to ensure that only one Customer User ID has access at a time, while still allowing users to log in with a different Customer User ID without losing their paid access. |
-| Requires customers to create an account before purchasing, with strict rules that tie purchases to a single Customer User ID. | Choose **Disabled** to ensure that transactions are never transferred between accounts. |
+You can transfer the product from one profile to another without sharing paid access. When you [delete a user profile](https://adapty.io/docs/api-adapty#/operations/deleteProfile), Adapty transfers access to the next available profile, whether anonymous or identified.

versioned_docs/version-3.0/access-level-sharing.md

@@ -96,9 +96,7 @@ It is important to consider that the selected option not only affects analytics
 
 Please ensure that you select the designated option that aligns with your desired approach to handling subscription prices for existing subscribers. This will help maintain accurate data and synchronization between Adapty analytics and the results obtained from the App Store Connect.
 
-## 6. Sharing purchases between user accounts
-
-When a <InlineTooltip tooltip="Customer User ID">[iOS](identifying-users#setting-customer-user-id-on-configuration), [Android](android-identifying-users#setting-customer-user-id-on-configuration), [React Native](react-native-identifying-users#setting-customer-user-id-on-configuration), [Flutter](flutter-identifying-users#setting-customer-user-id-on-configuration), and [Unity](unity-identifying-users#setting-customer-user-id-on-configuration)</InlineTooltip> tries to restore transactions or extend a subscription that is already associated with a different identified <InlineTooltip tooltip="Customer User ID">[iOS](identifying-users#setting-customer-user-id-on-configuration), [Android](android-identifying-users#setting-customer-user-id-on-configuration),[React Native](react-native-identifying-users#setting-customer-user-id-on-configuration), [Flutter](flutter-identifying-users#setting-customer-user-id-on-configuration), and [Unity](unity-identifying-users#setting-customer-user-id-on-configuration)</InlineTooltip>, you can control how Adapty responds by adjusting the **Sharing paid access between user accounts** dropdown:
+## 6. Sharing paid access between user accounts
 
 <Sharingaccesslevel />
 

versioned_docs/version-3.0/general.md

@@ -164,9 +164,7 @@ Why do events show future timestamps in profiles and integrations? Event timesta
 - **Impact on Analytics and Event Feed**: These events will only appear in **Analytics** and the **Event Feed** once their timestamps have passed. Events with future timestamps are not shown in either section.
 - **Impact on Integrations**: Adapty sends events to integrations as soon as they are received. If an event has a future timestamp, it will be shared with your integration exactly as received.
 
-## Sharing access levels between profiles
-
-When a [Customer User ID](identifying-users#setting-customer-user-id-on-configuration) tries to restore transactions or extend a subscription that is already associated with a different identified [Customer User ID](identifying-users#setting-customer-user-id-on-configuration), you can control how Adapty responds by adjusting the **Sharing paid access between user accounts** dropdown in the [Adapty Dashboard -> **App settings** -> **General** tab](https://app.adapty.io/settings/general):
+## Sharing paid access between user accounts
 
 <Sharingaccesslevel />