People & HR · Untermodul

Anpassungen: wann das Modul im Produktalltag Sinn ergibt.

Manuelle Korrekturen des Urlaubsanspruchs. Das Modul hat einen eigenen Einstiegspfad innerhalb des Produkts: /absences/adjustments.

  • Anpassungen erklärt kompakt, wofür der Bereich gedacht ist und wann er im Arbeitsalltag relevant wird.
  • Der Bereich spielt in der Praxis besonders mit Abwesenheit und Anträge zusammen.
  • Rollen, Sichtbarkeit und angrenzende Bereiche bestimmen, wie gut das Modul im Alltag funktioniert.
Modulzweck

Wofür das Modul gedacht ist

Anpassungen ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.

Manuelle Korrekturen des Urlaubsanspruchs. Im tenantweiten Kontext sorgt der Bereich dafür, dass wiederkehrende Entscheidungen, Stammdaten oder Übersichten nicht in Nebensysteme ausweichen müssen.

Anpassungen hängt fachlich an Abwesenheit. Dadurch ist für Nutzer sofort klar, in welchem größeren Ablauf das Modul seinen Platz hat.

Das Modul hat einen eigenen Einstiegspfad innerhalb des Produkts: /absences/adjustments.
Praxisbezug

Typische Einsatzfälle

Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.

Self-Service entlasten

Mitarbeitende können wiederkehrende Personalthemen direkt im passenden Ablauf bearbeiten.

Genehmigungspfade klären

Anträge, Korrekturen und Zielwerte bleiben transparent, sobald die zuständigen Rollen sauber gesetzt sind.

Kapazität planbar machen

Das Modul ist besonders wertvoll, wenn Abwesenheit, Soll-Werte und Stunden gemeinsam gedacht werden.

Modulverbindungen

Wie das Modul mit anderen Bereichen zusammenspielt

struct-i-vio ist als zusammenhängende Plattform gedacht. Diese Module liegen fachlich am nächsten bei diesem Bereich.

Sichtbarkeit

Berechtigungen und Sichtbarkeit

Die öffentliche Dokumentation beschreibt die Logik auf Produktniveau - nicht als technische Policy-Liste, sondern als Rollout-Leitfaden.

Die Sichtbarkeit wird tenantweit bzw. organisationsweit freigeschaltet und sollte zu Rolle und Verantwortungsbereich passen.
Anpassungen ist fachlich an Abwesenheit angebunden. Die Gruppe kann sichtbar sein, obwohl einzelne Detailrechte enger gesetzt bleiben.
Self-Service, Genehmigung und manuelle Korrektur sollten getrennt vergeben werden, damit sensible Personaldaten nicht unnötig breit sichtbar sind.
Empfohlener Einsatz

Best Practices

So bleibt der Bereich bei Einführung und Nutzung anschlussfähig an den restlichen Produktfluss.

Antrags- und Genehmigungswege bewusst definieren, bevor das Modul tenantweit ausgerollt wird.
Personalseitige Regeln mit Stunden- und Kapazitätsprozessen abstimmen, damit Teams nicht in Parallelstrukturen arbeiten.
Korrekturen und Overrides immer auf einen kleinen, nachvollziehbaren Kreis begrenzen.
Tiefer einsteigen

Entwickler Info

Klein, sauber, RLS-only. Drei Permissions auf vacation_balance_adjustments: view (SELECT), create (INSERT+UPDATE) und delete (DELETE).

Entwickler-Info aufklappen (1)

INSERT und UPDATE teilen sich den create-Toggle

vacation_balance_adjustments_insert UND _update prüfen beide create. Wer Korrekturen anlegen darf, kann sie auch nachträglich ändern. Eine separate "edit"-Permission existiert nicht.

  • RLS: public.vacation_balance_adjustments :: _insert + _update