diff --git a/10/umbraco-cms/reference/notifications/contentservice-notifications.md b/10/umbraco-cms/reference/notifications/contentservice-notifications.md
index fdaa4158942..e891bef3004 100644
--- a/10/umbraco-cms/reference/notifications/contentservice-notifications.md
+++ b/10/umbraco-cms/reference/notifications/contentservice-notifications.md
@@ -173,12 +173,56 @@ bool IsCultureEdited(string culture);
bool IsCulturePublished(string culture);
```
-### What happened to Creating and Created events?
+
+
+What happened to Creating and Created events?
Both the ContentService.Creating and ContentService.Created events were removed, and therefore never moved to notifications. Why? Because these events were not guaranteed to trigger and therefore should not be used. This is because these events would only trigger when the ContentService.CreateContent method was used which is an entirely optional way to create content entities. It is also possible to construct a new content item - which is generally the preferred and consistent way - and therefore the Creating/Created events would not execute when constructing content that way.
Furthermore, there was no reason to listen to the Creating/Created events. They were misleading since they didn't trigger before and after the entity persisted. They are triggered inside the CreateContent method which never persists the entity, it constructs a new content object.
-#### What do we use instead?
+**What do we use instead?**
The ContentSavingNotification and ContentSavedNotification will always be published before and after an entity has been persisted. You can determine if an entity is brand new in either of those notifications. In the Saving notification - before the entity is persisted - you can check the entity's HasIdentity property which will be 'false' if it is brand new. In the Saved notification you can [check to see if the entity 'remembers being dirty'](determining-new-entity.md)
+
+
+
+
+
+What happened to `raiseEvent` method parameters?
+
+RaiseEvent method service parameters have been removed from v9 and to name some reasons why:
+
+- Because it's entirely inconsistent, not all services have this as method parameters and maintaining that consistency is impossible especially if 3rd party libraries support events/notifications.
+- It's hacky. There's no good way to suppress events/notifications this way at a higher (scoped) level.
+- There's also hard-coded logic to ignore these parameters sometimes which makes it even more inconsistent.
+- There are events below services at the repository level that cannot be controlled by this flag.
+
+**What do we use instead?**
+
+We can suppress notifications at the scope level which makes things consistent and will work for all services that use a Scope. Also, there's no required maintenance to make sure that new service methods will also work.
+
+**How to use scopes**:
+
+- Create an explicit scope and call scope.Notifications.Supress().
+- The result of Suppress() is IDisposable, so until it is disposed, notifications will not be added to the queue.
+
+[Example](https://github.com/umbraco/Umbraco-CMS/blob/b69afe81f3f6fcd37480b3b0295a62af44ede245/tests/Umbraco.Tests.Integration/Umbraco.Infrastructure/Scoping/SupressNotificationsTests.cs#L35):
+
+```csharp
+using (IScope scope = ScopeProvider.CreateScope(autoComplete: true))
+using (IDisposable _ = scope.Notifications.Supress())
+{
+ // TODO: Calls to service methods here will not have notifications
+}
+```
+
+Child scope will inherit the parent Scope's notification object which means if a parent scope has notifications suppressed, then so does the child scope. You cannot call Supress() more than once for the same outer scope instance else an exception will be thrown. This ensures that you cannot un-suppress notifications at a child level for an outer scope. It also ensures that suppressing events is an explicit thing to do.
+
+**Why would one want to suppress events?**
+
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+
+So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
+
+
diff --git a/10/umbraco-cms/reference/notifications/mediaservice-notifications.md b/10/umbraco-cms/reference/notifications/mediaservice-notifications.md
index 31cc1c1083f..c70438733aa 100644
--- a/10/umbraco-cms/reference/notifications/mediaservice-notifications.md
+++ b/10/umbraco-cms/reference/notifications/mediaservice-notifications.md
@@ -81,12 +81,56 @@ namespace MyProject
-### What happened to Creating and Created events?
+
+
+What happened to Creating and Created events?
Both the MediaService.Creating and MediaService.Created events have been obsoleted. Because of this, these were not moved over to notifications, and no longer exist. Why? Because these events were not guaranteed to trigger and therefore should not have been used. This is because these events *only* triggered when the MediaService.CreateMedia method was used which is an entirely optional way to create media entities. It is also possible to construct a new media item - which is generally the preferred and consistent way - and therefore the Creating/Created events would not execute when constructing media that way.
Furthermore, there was no reason to listen for the Creating/Created events because they were misleading. They didn't trigger before and after the entity had been persisted. Instead they triggered inside the CreateMedia method which never persists the entity. It constructs a new media object.
-#### What do we use instead?
+**What do we use instead?**
The MediaSavingNotification and MediaSavedNotification will always be published before and after an entity has been persisted. You can determine if an entity is brand new with either of those notifications. With the Saving notification - before the entity is persisted - you can check the entity's HasIdentity property which will be 'false' if it is brand new. In the Saved event you can [check to see if the entity 'remembers being dirty'](determining-new-entity.md)
+
+
+
+
+
+What happened to `raiseEvent` method parameters?
+
+RaiseEvent method service parameters have been removed from v9 and to name some reasons why:
+
+- Because it's entirely inconsistent, not all services have this as method parameters and maintaining that consistency is impossible especially if 3rd party libraries support events/notifications.
+- It's hacky. There's no good way to suppress events/notifications this way at a higher (scoped) level.
+- There's also hard-coded logic to ignore these parameters sometimes which makes it even more inconsistent.
+- There are events below services at the repository level that cannot be controlled by this flag.
+
+**What do we use instead?**
+
+We can suppress notifications at the scope level which makes things consistent and will work for all services that use a Scope. Also, there's no required maintenance to make sure that new service methods will also work.
+
+**How to use scopes**:
+
+- Create an explicit scope and call scope.Notifications.Supress().
+- The result of Suppress() is IDisposable, so until it is disposed, notifications will not be added to the queue.
+
+[Example](https://github.com/umbraco/Umbraco-CMS/blob/b69afe81f3f6fcd37480b3b0295a62af44ede245/tests/Umbraco.Tests.Integration/Umbraco.Infrastructure/Scoping/SupressNotificationsTests.cs#L35):
+
+```csharp
+using (IScope scope = ScopeProvider.CreateScope(autoComplete: true))
+using (IDisposable _ = scope.Notifications.Supress())
+{
+ // TODO: Calls to service methods here will not have notifications
+}
+```
+
+Child scope will inherit the parent Scope's notification object which means if a parent scope has notifications suppressed, then so does the child scope. You cannot call Supress() more than once for the same outer scope instance else an exception will be thrown. This ensures that you cannot un-suppress notifications at a child level for an outer scope. It also ensures that suppressing events is an explicit thing to do.
+
+**Why would one want to suppress events?**
+
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+
+So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
+
+
diff --git a/10/umbraco-cms/reference/notifications/memberservice-notifications.md b/10/umbraco-cms/reference/notifications/memberservice-notifications.md
index 95255854483..e87a82c26a6 100644
--- a/10/umbraco-cms/reference/notifications/memberservice-notifications.md
+++ b/10/umbraco-cms/reference/notifications/memberservice-notifications.md
@@ -35,3 +35,43 @@ namespace MySite
}
}
```
+
+
+
+What happened to `raiseEvent` method parameters?
+
+RaiseEvent method service parameters have been removed from v9 and to name some reasons why:
+
+- Because it's entirely inconsistent, not all services have this as method parameters and maintaining that consistency is impossible especially if 3rd party libraries support events/notifications.
+- It's hacky. There's no good way to suppress events/notifications this way at a higher (scoped) level.
+- There's also hard-coded logic to ignore these parameters sometimes which makes it even more inconsistent.
+- There are events below services at the repository level that cannot be controlled by this flag.
+
+**What do we use instead?**
+
+We can suppress notifications at the scope level which makes things consistent and will work for all services that use a Scope. Also, there's no required maintenance to make sure that new service methods will also work.
+
+**How to use scopes**:
+
+- Create an explicit scope and call scope.Notifications.Supress().
+- The result of Suppress() is IDisposable, so until it is disposed, notifications will not be added to the queue.
+
+[Example](https://github.com/umbraco/Umbraco-CMS/blob/b69afe81f3f6fcd37480b3b0295a62af44ede245/tests/Umbraco.Tests.Integration/Umbraco.Infrastructure/Scoping/SupressNotificationsTests.cs#L35):
+
+```csharp
+using (IScope scope = ScopeProvider.CreateScope(autoComplete: true))
+using (IDisposable _ = scope.Notifications.Supress())
+{
+ // TODO: Calls to service methods here will not have notifications
+}
+```
+
+Child scope will inherit the parent Scope's notification object which means if a parent scope has notifications suppressed, then so does the child scope. You cannot call Supress() more than once for the same outer scope instance else an exception will be thrown. This ensures that you cannot un-suppress notifications at a child level for an outer scope. It also ensures that suppressing events is an explicit thing to do.
+
+**Why would one want to suppress events?**
+
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+
+So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
+
+
diff --git a/12/umbraco-cms/reference/notifications/contentservice-notifications.md b/12/umbraco-cms/reference/notifications/contentservice-notifications.md
index 779c0cb6fc2..25f9207dacd 100644
--- a/12/umbraco-cms/reference/notifications/contentservice-notifications.md
+++ b/12/umbraco-cms/reference/notifications/contentservice-notifications.md
@@ -169,12 +169,56 @@ bool IsCultureEdited(string culture);
bool IsCulturePublished(string culture);
```
-### What happened to Creating and Created events?
+
+
+What happened to Creating and Created events?
Both the ContentService.Creating and ContentService.Created events were removed, and therefore never moved to notifications. Why? Because these events were not guaranteed to trigger and therefore should not be used. This is because these events would only trigger when the ContentService.CreateContent method was used which is an entirely optional way to create content entities. It is also possible to construct a new content item - which is generally the preferred and consistent way - and therefore the Creating/Created events would not execute when constructing content that way.
Furthermore, there was no reason to listen to the Creating/Created events. They were misleading since they didn't trigger before and after the entity persisted. They are triggered inside the CreateContent method which never persists the entity, it constructs a new content object.
-#### What do we use instead?
+**What do we use instead?**
+
+The ContentSavingNotification and ContentSavedNotification will always be published before and after an entity has been persisted. You can determine if an entity is brand new in either of those notifications. In the Saving notification - before the entity is persisted - you can check the entity's HasIdentity property which will be 'false' if it is brand new. In the Saved notification you can [check to see if the entity 'remembers being dirty'](determining-new-entity.md)
+
+
+
+
+
+What happened to `raiseEvent` method parameters?
+
+RaiseEvent method service parameters have been removed from v9 and to name some reasons why:
+
+- Because it's entirely inconsistent, not all services have this as method parameters and maintaining that consistency is impossible especially if 3rd party libraries support events/notifications.
+- It's hacky. There's no good way to suppress events/notifications this way at a higher (scoped) level.
+- There's also hard-coded logic to ignore these parameters sometimes which makes it even more inconsistent.
+- There are events below services at the repository level that cannot be controlled by this flag.
+
+**What do we use instead?**
+
+We can suppress notifications at the scope level which makes things consistent and will work for all services that use a Scope. Also, there's no required maintenance to make sure that new service methods will also work.
+
+**How to use scopes**:
+
+- Create an explicit scope and call scope.Notifications.Supress().
+- The result of Suppress() is IDisposable, so until it is disposed, notifications will not be added to the queue.
+
+[Example](https://github.com/umbraco/Umbraco-CMS/blob/b69afe81f3f6fcd37480b3b0295a62af44ede245/tests/Umbraco.Tests.Integration/Umbraco.Infrastructure/Scoping/SupressNotificationsTests.cs#L35):
+
+```csharp
+using (IScope scope = ScopeProvider.CreateScope(autoComplete: true))
+using (IDisposable _ = scope.Notifications.Supress())
+{
+ // TODO: Calls to service methods here will not have notifications
+}
+```
+
+Child scope will inherit the parent Scope's notification object which means if a parent scope has notifications suppressed, then so does the child scope. You cannot call Supress() more than once for the same outer scope instance else an exception will be thrown. This ensures that you cannot un-suppress notifications at a child level for an outer scope. It also ensures that suppressing events is an explicit thing to do.
+
+**Why would one want to suppress events?**
+
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+
+So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
-The ContentSavingNotification and ContentSavedNotification will always be published before and after an entity has been persisted. You can determine if an entity is brand new in either of those notifications. In the Saving notification - before the entity is persisted - you can check the entity's HasIdentity property which will be `false` if it is brand new. In the Saved notification you can [check to see if the entity 'remembers being dirty'](determining-new-entity.md)
+
diff --git a/12/umbraco-cms/reference/notifications/mediaservice-notifications.md b/12/umbraco-cms/reference/notifications/mediaservice-notifications.md
index 050e0b90027..d58c622ae7d 100644
--- a/12/umbraco-cms/reference/notifications/mediaservice-notifications.md
+++ b/12/umbraco-cms/reference/notifications/mediaservice-notifications.md
@@ -80,12 +80,56 @@ namespace MyProject
-### What happened to Creating and Created events?
+
-Both the MediaService.Creating and MediaService.Created events have been obsoleted. Because of this, these were not moved over to notifications, and no longer exist. Why? Because these events were not guaranteed to trigger and therefore should not have been used. This is because these events _only_ triggered when the MediaService.CreateMedia method was used which is an entirely optional way to create media entities. It is also possible to construct a new media item - which is generally the preferred and consistent way - and therefore the Creating/Created events would not execute when constructing media that way.
+What happened to Creating and Created events?
+
+Both the MediaService.Creating and MediaService.Created events have been obsoleted. Because of this, these were not moved over to notifications, and no longer exist. Why? Because these events were not guaranteed to trigger and therefore should not have been used. This is because these events *only* triggered when the MediaService.CreateMedia method was used which is an entirely optional way to create media entities. It is also possible to construct a new media item - which is generally the preferred and consistent way - and therefore the Creating/Created events would not execute when constructing media that way.
Furthermore, there was no reason to listen for the Creating/Created events because they were misleading. They didn't trigger before and after the entity had been persisted. Instead they triggered inside the CreateMedia method which never persists the entity. It constructs a new media object.
-#### What do we use instead?
+**What do we use instead?**
The MediaSavingNotification and MediaSavedNotification will always be published before and after an entity has been persisted. You can determine if an entity is brand new with either of those notifications. With the Saving notification - before the entity is persisted - you can check the entity's HasIdentity property which will be 'false' if it is brand new. In the Saved event you can [check to see if the entity 'remembers being dirty'](determining-new-entity.md)
+
+
+
+
+
+What happened to `raiseEvent` method parameters?
+
+RaiseEvent method service parameters have been removed from v9 and to name some reasons why:
+
+- Because it's entirely inconsistent, not all services have this as method parameters and maintaining that consistency is impossible especially if 3rd party libraries support events/notifications.
+- It's hacky. There's no good way to suppress events/notifications this way at a higher (scoped) level.
+- There's also hard-coded logic to ignore these parameters sometimes which makes it even more inconsistent.
+- There are events below services at the repository level that cannot be controlled by this flag.
+
+**What do we use instead?**
+
+We can suppress notifications at the scope level which makes things consistent and will work for all services that use a Scope. Also, there's no required maintenance to make sure that new service methods will also work.
+
+**How to use scopes**:
+
+- Create an explicit scope and call scope.Notifications.Supress().
+- The result of Suppress() is IDisposable, so until it is disposed, notifications will not be added to the queue.
+
+[Example](https://github.com/umbraco/Umbraco-CMS/blob/b69afe81f3f6fcd37480b3b0295a62af44ede245/tests/Umbraco.Tests.Integration/Umbraco.Infrastructure/Scoping/SupressNotificationsTests.cs#L35):
+
+```csharp
+using (IScope scope = ScopeProvider.CreateScope(autoComplete: true))
+using (IDisposable _ = scope.Notifications.Supress())
+{
+ // TODO: Calls to service methods here will not have notifications
+}
+```
+
+Child scope will inherit the parent Scope's notification object which means if a parent scope has notifications suppressed, then so does the child scope. You cannot call Supress() more than once for the same outer scope instance else an exception will be thrown. This ensures that you cannot un-suppress notifications at a child level for an outer scope. It also ensures that suppressing events is an explicit thing to do.
+
+**Why would one want to suppress events?**
+
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+
+So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
+
+
diff --git a/12/umbraco-cms/reference/notifications/memberservice-notifications.md b/12/umbraco-cms/reference/notifications/memberservice-notifications.md
index 1f5df2d9069..0d06cdc60bd 100644
--- a/12/umbraco-cms/reference/notifications/memberservice-notifications.md
+++ b/12/umbraco-cms/reference/notifications/memberservice-notifications.md
@@ -34,3 +34,43 @@ public class MemberNotificationHandler : INotificationHandler
+
+What happened to `raiseEvent` method parameters?
+
+RaiseEvent method service parameters have been removed from v9 and to name some reasons why:
+
+- Because it's entirely inconsistent, not all services have this as method parameters and maintaining that consistency is impossible especially if 3rd party libraries support events/notifications.
+- It's hacky. There's no good way to suppress events/notifications this way at a higher (scoped) level.
+- There's also hard-coded logic to ignore these parameters sometimes which makes it even more inconsistent.
+- There are events below services at the repository level that cannot be controlled by this flag.
+
+**What do we use instead?**
+
+We can suppress notifications at the scope level which makes things consistent and will work for all services that use a Scope. Also, there's no required maintenance to make sure that new service methods will also work.
+
+**How to use scopes**:
+
+- Create an explicit scope and call scope.Notifications.Supress().
+- The result of Suppress() is IDisposable, so until it is disposed, notifications will not be added to the queue.
+
+[Example](https://github.com/umbraco/Umbraco-CMS/blob/b69afe81f3f6fcd37480b3b0295a62af44ede245/tests/Umbraco.Tests.Integration/Umbraco.Infrastructure/Scoping/SupressNotificationsTests.cs#L35):
+
+```csharp
+using (IScope scope = ScopeProvider.CreateScope(autoComplete: true))
+using (IDisposable _ = scope.Notifications.Supress())
+{
+ // TODO: Calls to service methods here will not have notifications
+}
+```
+
+Child scope will inherit the parent Scope's notification object which means if a parent scope has notifications suppressed, then so does the child scope. You cannot call Supress() more than once for the same outer scope instance else an exception will be thrown. This ensures that you cannot un-suppress notifications at a child level for an outer scope. It also ensures that suppressing events is an explicit thing to do.
+
+**Why would one want to suppress events?**
+
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+
+So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
+
+
diff --git a/13/umbraco-cms/reference/notifications/contentservice-notifications.md b/13/umbraco-cms/reference/notifications/contentservice-notifications.md
index 779c0cb6fc2..25f9207dacd 100644
--- a/13/umbraco-cms/reference/notifications/contentservice-notifications.md
+++ b/13/umbraco-cms/reference/notifications/contentservice-notifications.md
@@ -169,12 +169,56 @@ bool IsCultureEdited(string culture);
bool IsCulturePublished(string culture);
```
-### What happened to Creating and Created events?
+
+
+What happened to Creating and Created events?
Both the ContentService.Creating and ContentService.Created events were removed, and therefore never moved to notifications. Why? Because these events were not guaranteed to trigger and therefore should not be used. This is because these events would only trigger when the ContentService.CreateContent method was used which is an entirely optional way to create content entities. It is also possible to construct a new content item - which is generally the preferred and consistent way - and therefore the Creating/Created events would not execute when constructing content that way.
Furthermore, there was no reason to listen to the Creating/Created events. They were misleading since they didn't trigger before and after the entity persisted. They are triggered inside the CreateContent method which never persists the entity, it constructs a new content object.
-#### What do we use instead?
+**What do we use instead?**
+
+The ContentSavingNotification and ContentSavedNotification will always be published before and after an entity has been persisted. You can determine if an entity is brand new in either of those notifications. In the Saving notification - before the entity is persisted - you can check the entity's HasIdentity property which will be 'false' if it is brand new. In the Saved notification you can [check to see if the entity 'remembers being dirty'](determining-new-entity.md)
+
+
+
+
+
+What happened to `raiseEvent` method parameters?
+
+RaiseEvent method service parameters have been removed from v9 and to name some reasons why:
+
+- Because it's entirely inconsistent, not all services have this as method parameters and maintaining that consistency is impossible especially if 3rd party libraries support events/notifications.
+- It's hacky. There's no good way to suppress events/notifications this way at a higher (scoped) level.
+- There's also hard-coded logic to ignore these parameters sometimes which makes it even more inconsistent.
+- There are events below services at the repository level that cannot be controlled by this flag.
+
+**What do we use instead?**
+
+We can suppress notifications at the scope level which makes things consistent and will work for all services that use a Scope. Also, there's no required maintenance to make sure that new service methods will also work.
+
+**How to use scopes**:
+
+- Create an explicit scope and call scope.Notifications.Supress().
+- The result of Suppress() is IDisposable, so until it is disposed, notifications will not be added to the queue.
+
+[Example](https://github.com/umbraco/Umbraco-CMS/blob/b69afe81f3f6fcd37480b3b0295a62af44ede245/tests/Umbraco.Tests.Integration/Umbraco.Infrastructure/Scoping/SupressNotificationsTests.cs#L35):
+
+```csharp
+using (IScope scope = ScopeProvider.CreateScope(autoComplete: true))
+using (IDisposable _ = scope.Notifications.Supress())
+{
+ // TODO: Calls to service methods here will not have notifications
+}
+```
+
+Child scope will inherit the parent Scope's notification object which means if a parent scope has notifications suppressed, then so does the child scope. You cannot call Supress() more than once for the same outer scope instance else an exception will be thrown. This ensures that you cannot un-suppress notifications at a child level for an outer scope. It also ensures that suppressing events is an explicit thing to do.
+
+**Why would one want to suppress events?**
+
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+
+So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
-The ContentSavingNotification and ContentSavedNotification will always be published before and after an entity has been persisted. You can determine if an entity is brand new in either of those notifications. In the Saving notification - before the entity is persisted - you can check the entity's HasIdentity property which will be `false` if it is brand new. In the Saved notification you can [check to see if the entity 'remembers being dirty'](determining-new-entity.md)
+
diff --git a/13/umbraco-cms/reference/notifications/mediaservice-notifications.md b/13/umbraco-cms/reference/notifications/mediaservice-notifications.md
index 050e0b90027..d58c622ae7d 100644
--- a/13/umbraco-cms/reference/notifications/mediaservice-notifications.md
+++ b/13/umbraco-cms/reference/notifications/mediaservice-notifications.md
@@ -80,12 +80,56 @@ namespace MyProject
-### What happened to Creating and Created events?
+
-Both the MediaService.Creating and MediaService.Created events have been obsoleted. Because of this, these were not moved over to notifications, and no longer exist. Why? Because these events were not guaranteed to trigger and therefore should not have been used. This is because these events _only_ triggered when the MediaService.CreateMedia method was used which is an entirely optional way to create media entities. It is also possible to construct a new media item - which is generally the preferred and consistent way - and therefore the Creating/Created events would not execute when constructing media that way.
+What happened to Creating and Created events?
+
+Both the MediaService.Creating and MediaService.Created events have been obsoleted. Because of this, these were not moved over to notifications, and no longer exist. Why? Because these events were not guaranteed to trigger and therefore should not have been used. This is because these events *only* triggered when the MediaService.CreateMedia method was used which is an entirely optional way to create media entities. It is also possible to construct a new media item - which is generally the preferred and consistent way - and therefore the Creating/Created events would not execute when constructing media that way.
Furthermore, there was no reason to listen for the Creating/Created events because they were misleading. They didn't trigger before and after the entity had been persisted. Instead they triggered inside the CreateMedia method which never persists the entity. It constructs a new media object.
-#### What do we use instead?
+**What do we use instead?**
The MediaSavingNotification and MediaSavedNotification will always be published before and after an entity has been persisted. You can determine if an entity is brand new with either of those notifications. With the Saving notification - before the entity is persisted - you can check the entity's HasIdentity property which will be 'false' if it is brand new. In the Saved event you can [check to see if the entity 'remembers being dirty'](determining-new-entity.md)
+
+
+
+
+
+What happened to `raiseEvent` method parameters?
+
+RaiseEvent method service parameters have been removed from v9 and to name some reasons why:
+
+- Because it's entirely inconsistent, not all services have this as method parameters and maintaining that consistency is impossible especially if 3rd party libraries support events/notifications.
+- It's hacky. There's no good way to suppress events/notifications this way at a higher (scoped) level.
+- There's also hard-coded logic to ignore these parameters sometimes which makes it even more inconsistent.
+- There are events below services at the repository level that cannot be controlled by this flag.
+
+**What do we use instead?**
+
+We can suppress notifications at the scope level which makes things consistent and will work for all services that use a Scope. Also, there's no required maintenance to make sure that new service methods will also work.
+
+**How to use scopes**:
+
+- Create an explicit scope and call scope.Notifications.Supress().
+- The result of Suppress() is IDisposable, so until it is disposed, notifications will not be added to the queue.
+
+[Example](https://github.com/umbraco/Umbraco-CMS/blob/b69afe81f3f6fcd37480b3b0295a62af44ede245/tests/Umbraco.Tests.Integration/Umbraco.Infrastructure/Scoping/SupressNotificationsTests.cs#L35):
+
+```csharp
+using (IScope scope = ScopeProvider.CreateScope(autoComplete: true))
+using (IDisposable _ = scope.Notifications.Supress())
+{
+ // TODO: Calls to service methods here will not have notifications
+}
+```
+
+Child scope will inherit the parent Scope's notification object which means if a parent scope has notifications suppressed, then so does the child scope. You cannot call Supress() more than once for the same outer scope instance else an exception will be thrown. This ensures that you cannot un-suppress notifications at a child level for an outer scope. It also ensures that suppressing events is an explicit thing to do.
+
+**Why would one want to suppress events?**
+
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+
+So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
+
+
diff --git a/13/umbraco-cms/reference/notifications/memberservice-notifications.md b/13/umbraco-cms/reference/notifications/memberservice-notifications.md
index 1f5df2d9069..0d06cdc60bd 100644
--- a/13/umbraco-cms/reference/notifications/memberservice-notifications.md
+++ b/13/umbraco-cms/reference/notifications/memberservice-notifications.md
@@ -34,3 +34,43 @@ public class MemberNotificationHandler : INotificationHandler
+
+What happened to `raiseEvent` method parameters?
+
+RaiseEvent method service parameters have been removed from v9 and to name some reasons why:
+
+- Because it's entirely inconsistent, not all services have this as method parameters and maintaining that consistency is impossible especially if 3rd party libraries support events/notifications.
+- It's hacky. There's no good way to suppress events/notifications this way at a higher (scoped) level.
+- There's also hard-coded logic to ignore these parameters sometimes which makes it even more inconsistent.
+- There are events below services at the repository level that cannot be controlled by this flag.
+
+**What do we use instead?**
+
+We can suppress notifications at the scope level which makes things consistent and will work for all services that use a Scope. Also, there's no required maintenance to make sure that new service methods will also work.
+
+**How to use scopes**:
+
+- Create an explicit scope and call scope.Notifications.Supress().
+- The result of Suppress() is IDisposable, so until it is disposed, notifications will not be added to the queue.
+
+[Example](https://github.com/umbraco/Umbraco-CMS/blob/b69afe81f3f6fcd37480b3b0295a62af44ede245/tests/Umbraco.Tests.Integration/Umbraco.Infrastructure/Scoping/SupressNotificationsTests.cs#L35):
+
+```csharp
+using (IScope scope = ScopeProvider.CreateScope(autoComplete: true))
+using (IDisposable _ = scope.Notifications.Supress())
+{
+ // TODO: Calls to service methods here will not have notifications
+}
+```
+
+Child scope will inherit the parent Scope's notification object which means if a parent scope has notifications suppressed, then so does the child scope. You cannot call Supress() more than once for the same outer scope instance else an exception will be thrown. This ensures that you cannot un-suppress notifications at a child level for an outer scope. It also ensures that suppressing events is an explicit thing to do.
+
+**Why would one want to suppress events?**
+
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+
+So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
+
+
diff --git a/14/umbraco-cms/reference/notifications/contentservice-notifications.md b/14/umbraco-cms/reference/notifications/contentservice-notifications.md
index 779c0cb6fc2..25f9207dacd 100644
--- a/14/umbraco-cms/reference/notifications/contentservice-notifications.md
+++ b/14/umbraco-cms/reference/notifications/contentservice-notifications.md
@@ -169,12 +169,56 @@ bool IsCultureEdited(string culture);
bool IsCulturePublished(string culture);
```
-### What happened to Creating and Created events?
+
+
+What happened to Creating and Created events?
Both the ContentService.Creating and ContentService.Created events were removed, and therefore never moved to notifications. Why? Because these events were not guaranteed to trigger and therefore should not be used. This is because these events would only trigger when the ContentService.CreateContent method was used which is an entirely optional way to create content entities. It is also possible to construct a new content item - which is generally the preferred and consistent way - and therefore the Creating/Created events would not execute when constructing content that way.
Furthermore, there was no reason to listen to the Creating/Created events. They were misleading since they didn't trigger before and after the entity persisted. They are triggered inside the CreateContent method which never persists the entity, it constructs a new content object.
-#### What do we use instead?
+**What do we use instead?**
+
+The ContentSavingNotification and ContentSavedNotification will always be published before and after an entity has been persisted. You can determine if an entity is brand new in either of those notifications. In the Saving notification - before the entity is persisted - you can check the entity's HasIdentity property which will be 'false' if it is brand new. In the Saved notification you can [check to see if the entity 'remembers being dirty'](determining-new-entity.md)
+
+
+
+
+
+What happened to `raiseEvent` method parameters?
+
+RaiseEvent method service parameters have been removed from v9 and to name some reasons why:
+
+- Because it's entirely inconsistent, not all services have this as method parameters and maintaining that consistency is impossible especially if 3rd party libraries support events/notifications.
+- It's hacky. There's no good way to suppress events/notifications this way at a higher (scoped) level.
+- There's also hard-coded logic to ignore these parameters sometimes which makes it even more inconsistent.
+- There are events below services at the repository level that cannot be controlled by this flag.
+
+**What do we use instead?**
+
+We can suppress notifications at the scope level which makes things consistent and will work for all services that use a Scope. Also, there's no required maintenance to make sure that new service methods will also work.
+
+**How to use scopes**:
+
+- Create an explicit scope and call scope.Notifications.Supress().
+- The result of Suppress() is IDisposable, so until it is disposed, notifications will not be added to the queue.
+
+[Example](https://github.com/umbraco/Umbraco-CMS/blob/b69afe81f3f6fcd37480b3b0295a62af44ede245/tests/Umbraco.Tests.Integration/Umbraco.Infrastructure/Scoping/SupressNotificationsTests.cs#L35):
+
+```csharp
+using (IScope scope = ScopeProvider.CreateScope(autoComplete: true))
+using (IDisposable _ = scope.Notifications.Supress())
+{
+ // TODO: Calls to service methods here will not have notifications
+}
+```
+
+Child scope will inherit the parent Scope's notification object which means if a parent scope has notifications suppressed, then so does the child scope. You cannot call Supress() more than once for the same outer scope instance else an exception will be thrown. This ensures that you cannot un-suppress notifications at a child level for an outer scope. It also ensures that suppressing events is an explicit thing to do.
+
+**Why would one want to suppress events?**
+
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+
+So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
-The ContentSavingNotification and ContentSavedNotification will always be published before and after an entity has been persisted. You can determine if an entity is brand new in either of those notifications. In the Saving notification - before the entity is persisted - you can check the entity's HasIdentity property which will be `false` if it is brand new. In the Saved notification you can [check to see if the entity 'remembers being dirty'](determining-new-entity.md)
+
diff --git a/14/umbraco-cms/reference/notifications/mediaservice-notifications.md b/14/umbraco-cms/reference/notifications/mediaservice-notifications.md
index 050e0b90027..d58c622ae7d 100644
--- a/14/umbraco-cms/reference/notifications/mediaservice-notifications.md
+++ b/14/umbraco-cms/reference/notifications/mediaservice-notifications.md
@@ -80,12 +80,56 @@ namespace MyProject
-### What happened to Creating and Created events?
+
-Both the MediaService.Creating and MediaService.Created events have been obsoleted. Because of this, these were not moved over to notifications, and no longer exist. Why? Because these events were not guaranteed to trigger and therefore should not have been used. This is because these events _only_ triggered when the MediaService.CreateMedia method was used which is an entirely optional way to create media entities. It is also possible to construct a new media item - which is generally the preferred and consistent way - and therefore the Creating/Created events would not execute when constructing media that way.
+What happened to Creating and Created events?
+
+Both the MediaService.Creating and MediaService.Created events have been obsoleted. Because of this, these were not moved over to notifications, and no longer exist. Why? Because these events were not guaranteed to trigger and therefore should not have been used. This is because these events *only* triggered when the MediaService.CreateMedia method was used which is an entirely optional way to create media entities. It is also possible to construct a new media item - which is generally the preferred and consistent way - and therefore the Creating/Created events would not execute when constructing media that way.
Furthermore, there was no reason to listen for the Creating/Created events because they were misleading. They didn't trigger before and after the entity had been persisted. Instead they triggered inside the CreateMedia method which never persists the entity. It constructs a new media object.
-#### What do we use instead?
+**What do we use instead?**
The MediaSavingNotification and MediaSavedNotification will always be published before and after an entity has been persisted. You can determine if an entity is brand new with either of those notifications. With the Saving notification - before the entity is persisted - you can check the entity's HasIdentity property which will be 'false' if it is brand new. In the Saved event you can [check to see if the entity 'remembers being dirty'](determining-new-entity.md)
+
+
+
+
+
+What happened to `raiseEvent` method parameters?
+
+RaiseEvent method service parameters have been removed from v9 and to name some reasons why:
+
+- Because it's entirely inconsistent, not all services have this as method parameters and maintaining that consistency is impossible especially if 3rd party libraries support events/notifications.
+- It's hacky. There's no good way to suppress events/notifications this way at a higher (scoped) level.
+- There's also hard-coded logic to ignore these parameters sometimes which makes it even more inconsistent.
+- There are events below services at the repository level that cannot be controlled by this flag.
+
+**What do we use instead?**
+
+We can suppress notifications at the scope level which makes things consistent and will work for all services that use a Scope. Also, there's no required maintenance to make sure that new service methods will also work.
+
+**How to use scopes**:
+
+- Create an explicit scope and call scope.Notifications.Supress().
+- The result of Suppress() is IDisposable, so until it is disposed, notifications will not be added to the queue.
+
+[Example](https://github.com/umbraco/Umbraco-CMS/blob/b69afe81f3f6fcd37480b3b0295a62af44ede245/tests/Umbraco.Tests.Integration/Umbraco.Infrastructure/Scoping/SupressNotificationsTests.cs#L35):
+
+```csharp
+using (IScope scope = ScopeProvider.CreateScope(autoComplete: true))
+using (IDisposable _ = scope.Notifications.Supress())
+{
+ // TODO: Calls to service methods here will not have notifications
+}
+```
+
+Child scope will inherit the parent Scope's notification object which means if a parent scope has notifications suppressed, then so does the child scope. You cannot call Supress() more than once for the same outer scope instance else an exception will be thrown. This ensures that you cannot un-suppress notifications at a child level for an outer scope. It also ensures that suppressing events is an explicit thing to do.
+
+**Why would one want to suppress events?**
+
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+
+So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
+
+
diff --git a/14/umbraco-cms/reference/notifications/memberservice-notifications.md b/14/umbraco-cms/reference/notifications/memberservice-notifications.md
index 1f5df2d9069..0d06cdc60bd 100644
--- a/14/umbraco-cms/reference/notifications/memberservice-notifications.md
+++ b/14/umbraco-cms/reference/notifications/memberservice-notifications.md
@@ -34,3 +34,43 @@ public class MemberNotificationHandler : INotificationHandler
+
+What happened to `raiseEvent` method parameters?
+
+RaiseEvent method service parameters have been removed from v9 and to name some reasons why:
+
+- Because it's entirely inconsistent, not all services have this as method parameters and maintaining that consistency is impossible especially if 3rd party libraries support events/notifications.
+- It's hacky. There's no good way to suppress events/notifications this way at a higher (scoped) level.
+- There's also hard-coded logic to ignore these parameters sometimes which makes it even more inconsistent.
+- There are events below services at the repository level that cannot be controlled by this flag.
+
+**What do we use instead?**
+
+We can suppress notifications at the scope level which makes things consistent and will work for all services that use a Scope. Also, there's no required maintenance to make sure that new service methods will also work.
+
+**How to use scopes**:
+
+- Create an explicit scope and call scope.Notifications.Supress().
+- The result of Suppress() is IDisposable, so until it is disposed, notifications will not be added to the queue.
+
+[Example](https://github.com/umbraco/Umbraco-CMS/blob/b69afe81f3f6fcd37480b3b0295a62af44ede245/tests/Umbraco.Tests.Integration/Umbraco.Infrastructure/Scoping/SupressNotificationsTests.cs#L35):
+
+```csharp
+using (IScope scope = ScopeProvider.CreateScope(autoComplete: true))
+using (IDisposable _ = scope.Notifications.Supress())
+{
+ // TODO: Calls to service methods here will not have notifications
+}
+```
+
+Child scope will inherit the parent Scope's notification object which means if a parent scope has notifications suppressed, then so does the child scope. You cannot call Supress() more than once for the same outer scope instance else an exception will be thrown. This ensures that you cannot un-suppress notifications at a child level for an outer scope. It also ensures that suppressing events is an explicit thing to do.
+
+**Why would one want to suppress events?**
+
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+
+So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
+
+