Notification systems are complex and often case-specific.
I have never found a single one-size-fits-all solution for notifications in the last 20 years.
Don't rush to put all of your notifications in one place and assume you're done.
It's a great idea to have a centralised list of all past and current notifications that the user can check if they need to but that's not going to satisfy the need of each active notification case.
You need to figure out all the notifications your system needs to produce. I like to work with 4 different classes:
non-important and non-urgent: the user can act on these whenever they feel the time is right for them. They can also be dismissed without worry. These can be things like software tours, new features, etc
important but non-urgent: These require that action MUST be taken but any time within a given space of time is OK. These could be things like password renewals or software update reminders.
urgent but non-important: These must be dealt with immediately but can be simply dismissed if the user feels they are irrelevant. These could be things like timesheet reminders or sessions length reminders.
urgent and important: These cannot simply be dismissed and must be acted on immediately. These are reserved for those moments when the system cannot allow the user to carry on without completing some specific task or answering a particular question - Things like sanity checks or validation errors.
Each of these classes will have a whole list of contexts that need to be understood before we can work out how best to present them to the user.
Depending on the class and context of the notification, the presentation could range anywhere from a tiny dot or note in small text somewhere where it won't get in the way to a full-blown dialogue box that prevents the user from taking any other actions until the issue is resolved.
You will need to figure out the class and context for each notification before you can understand the best way/place to show it.