Responsibility
What It Is
A responsibility records organizational accountability for an area of work. Batch posting, reconciliation and financial close are examples of areas an application can declare. A holding then says which person or role looks after that area, for the whole workspace or a supported unit, during a defined period. This gives staff an explicit explanation of why particular work reaches them.
The application declaration provides the area’s label and scope choices. It can also describe default roles, required coverage, backup visibility and a fallback area. These choices support both a small organization relying on defaults and a larger one with named primary holders at particular units. The continuing area and its dated assignments remain separate, allowing accountability to change without redefining the business concern.
What It Is Not
A responsibility confers no authority to read or modify the underlying record. Security remains responsible for access. It also does not describe an individual task or checklist. Assigning batch posting identifies whose attention should be engaged, rather than creating a task for each batch. Team membership is another neighboring idea, and team holders are not implemented here.
How It Is Used
Administrators review the catalogue in responsibility settings and choose holders. Staff inspect My Responsibilities to understand direct holdings, role defaults, derived ownership and temporary cover. Someone going on leave can arrange a colleague’s cover for eligible direct assignments. The colleague’s Home identifies that arrangement and includes the relevant items. Uncovered areas become visible to administrators so they can decide who should hold them. Attempts to duplicate a holding or arrange invalid cover are rejected.
Its Facets
Declared area. Application registration names the concern, allowed scopes, coverage and fallback behavior. Giving staff a stable description of the work requiring ownership.
Dated holding. A person or role holds the area as primary or backup within an allowed scope and period. Matching current work to accountable people.
Default role. A retained assignment names a product role and supports workspace removal or narrowing. Providing useful initial coverage without individual setup.
Record-derived ownership. An application synchronizes holdings from its own business records. Following ownership already maintained at the source.
Temporary cover. A colleague covers an eligible assignment for a bounded period. Maintaining continuity during leave or other absence.
Coverage gap. The report identifies always-held areas without a workspace primary. Prompting administrators to restore accountability.
Change notices. Notifications explain assignment endings, new holdings and handovers to affected people. Making changed expectations visible without self-action noise.
How It Relates
Attention uses responsibility holdings to resolve recipients during a read. This makes current accountability relevant without rewriting every item after reassignment. Application records own resource identities and any derivation of holders. Security supplies the roles expanded from defaults, while Notifications carries responsibility notices. Responsibility records preserve accountability history rather than becoming another authorization source.
What It Could Become
The product should consider team holders and reusable assignment arrangements only with a clear ownership model. Customer-defined areas remain held for a later decision. Scope-specific management authority and organizational-unit selection have delivery limitations. Inactive delegates are reported without automatic termination, leaving a future policy choice about how organizations should repair that coverage.