When members of the team are creating pages for a Wiki, I have to find the document, and manually enable page notifications and comment notifications.
This is exhausting and open to user error.
How can I ensure that this is automatically enabled for any content in a given application?
I'm already a member of the group.
The only "automatic" way I know of is to use Daily Digests, but I'm not 100% sure that digests cover both page updates AND comment notifications.
I had a similar issue that has been evolving over time. I had (have?) a "Tip of the Week" wiki, but users wouldn't be alerted when a new page was added. To initially solve this, I'd have members subscribe to the wiki home page, I'd update the content ONLY on that page, and then create a new wiki sub-page with the prior tip. You can somewhat see this if you look at this history log https://sugarclub.sugarcrm.com/docs_and_resources/w/tip-of-the-week/278/defaultwikipage/revision/30. This was a lot of busywork on my end, but made it easy for those that read the content.
Recently, we launched this new group, https://sugarclub.sugarcrm.com/docs_and_resources, which contains the aforementioned wiki. The team at my company that is responsible for the content (among other content) will be creating forum posts (I was going to use Status Updates, but those don't send notifications either 
). I turned off most of the "forum" functionality in this group, but it's definitely the most reliable notification system. You can see my example forum post here: https://sugarclub.sugarcrm.com/docs_and_resources/f/updates/6875/3-november-2023. It's still open to user error as you said, but the team that manages this is small (6-7 people?). They're very meticulous, manage our product documentation, and are very comfortable with content-management processes like this.
Any other solution, to my knowledge, would be automation. This doesn't seem to be covered by Subscribe Users To Group Applications or Subscription Management Bundle . My guess is using WikiPage.AfterCreate and WikiPage.AfterUpdate, you'd pull a list of the related group members (or managers, or owners) and enable page notifications and comment notifications for the members in that list. It might get complicated due to the lack of notification options for Wikis in general ( When are email notifications triggered to subscribers? )
Daily Digests is really the only Out of The Box Way to achieve this - a digest should cover new content and comments in a given group.
For our members, this is like removing a dam's floodgates compared to turning on a tap. They don't want to receive digests for content, immediate notifications for other content (in this case forums), and result in a flooded mailbox. There are also members who want to solely receive notifications via the website and not via e-mail.
From a user experience, it's entirely befuddling to them that different content types are treated so drastically differently - for example, you can't even get a direct link to wiki comments in notifications or e-mails, but you can manually directly link to these comments.
An answer I was looking for with this thread is "Is this capable out of the box, or will it have to be a customisation, and will this have to be raised as another idea?" I basically have that answer thanks to the input from you and Alex 
Daily Digests is really the only Out of The Box Way to achieve this - a digest should cover new content and comments in a given group.
For our members, this is like removing a dam's floodgates compared to turning on a tap. They don't want to receive digests for content, immediate notifications for other content (in this case forums), and result in a flooded mailbox. There are also members who want to solely receive notifications via the website and not via e-mail.
From a user experience, it's entirely befuddling to them that different content types are treated so drastically differently - for example, you can't even get a direct link to wiki comments in notifications or e-mails, but you can manually directly link to these comments.
An answer I was looking for with this thread is "Is this capable out of the box, or will it have to be a customisation, and will this have to be raised as another idea?" I basically have that answer thanks to the input from you and Alex
