Dit artikel gaat over geautomatiseerde notificaties en signalen.
De software kan ingericht worden met geautomatiseerde notificaties. Deze notificaties kunnen in de vorm van een taak of een e-mail naar de belanghebbenden verstuurd worden.
Signalering #
Signalering bestaat uit 3 stappen:
- De trigger (voorwaarde) waarop het signaal moet afgaan; bijvoorbeeld x dagen voor einde contractdatum.
- Tekstueel samenvoegen van de mail/taak (op basis van een sjabloon);
- Versturen naar de ontvanger (doel).
De ontvanger van een signaleringstaak of e-mail onderscheiden we in de software in 3 typen (doelen).
Een signaal-item kan slechts één doel hebben:
- Een gebruiker: je kunt een gebruikersaccount koppelen en dat betekent dat het signaal alleen naar deze gebruiker verstuurd wordt. Er is dus slechts één ontvanger mogelijk. Een gebruiker heeft bovendien geen relatie met een organisatorische eenheid, dus contractmeldingen zullen ongefilterd (lees van alle medewerkers in het systeem) naar deze gebruiker verstuurd worden.
- Een rol: het is mogelijk om signalering naar gebruikersaccounts te sturen waarbij een bepaalde rol is ingesteld. Er kunnen meer gebruikers zijn met deze rol en daardoor is het mogelijk om meer dan één ontvanger van het signaal te hebben. Een rol heeft evenals de gebruiker geen relatie met een organisatorische eenheid, dus de meldingen zullen ongefilterd naar de ontvangers gestuurd worden.
- Een relatief: dit is een vooraf ingestelde ontvanger. M.a.w. er bestaat een relatie tussen het onderwerp van het signaal en de ontvanger. Het soort relatief bepaalt hoeveel ontvangers er mogelijk zijn. Zo is er slechts één afdelingsmanager per afdeling te koppelen, dus het relatief ‘Afdelingsmanager’ heeft één ontvanger. Maar er zijn wel 300 medewerkers op een rooster mogelijk, dus het relatief ‘Medewerkers van een rooster’ kan tot zoveel ontvangers hebben. Op basis van relatie tussen onderwerp en het doel kan nu wel filtering van signalen plaatsvinden en dat betekent dat doel ‘afdelingsmanager’ alleen van zijn/haar afdeling de signalen ontvangt en niet meer systeembreed.
Signalering typen #
Er zijn twee nieuwe signalen ontwikkeld om gebruikers van de urenregistratie te signaleren over de registratie van tijdelijke medewerkers op een afdeling.
Het eerste signaal Tijdelijke medewerker voor roosteren en urenregistratie toegevoegd is bedoeld om gebruikers met de P&O rol te informeren dat er een tijdelijke medewerker aan een afdeling/locatie is toegevoegd.
| Replacement SQLid | Medewerker tijdelijk uitgeleend aan een afdeling replacement |
| Brontabel voor replacement | TijdelijkeMedewerkers (tblTimesheetTemporaryEmployment) |
Het tweede signaal Medewerker heeft uren geboekt op een afdeling waarvoor hij niet is aangemeld als tijdelijke medewerker signaleert wanneer er uren geboekt zijn op een afdeling waar geen actuele inlening actief is.
| Replacement SQLid | Medewerker heeft uren geboekt op een afdeling waarvoor hij niet is uitgeleend replacement |
| Brontabel voor replacement | TijdelijkeMedewerkers niet gevuld (tblTimesheetTemporaryEmploymentNotSet) |
Praktijkvoorbeelden #
Voor afdeling ‘Banqueting’ is Niels de ingestelde manager; Niels is dus relatief doel van het contractsignaal. Dit signaal wordt gefilterd, hij ontvangt alleen de contractmeldingen binnen de afdeling.
Martin is de verlofmanager van medewerker Sanne. Als Sanne verlof aanvraagt gaat er een signaal naar het relatief ‘Verlofmanager’. In dit geval is dat Martin.
Echter is het sinds kort mogelijk om meer dan één verlofmanager per afdeling in te stellen en de verlofmanager en de afdelingsmanager zijn niet meer perse dezelfde persoon.
Laatste voorbeeld (doel rol/gebruiker):
Jan en Laura hebben beide een gebruikersaccount met daarin de rol ‘Verzuimmanager’. Van iedere medewerker die zich ziekmeldt zal het verzuimsignaal gaan naar zowel Jan als Laura. Er bestaat geen afdelingsfilter op het doel gebruiker of rol.
