Artikler om: AdminFlow Byrå

Project Leader (Responsible Accountant) and Engagement Responsible in Adminflow – Roles and Special Logic

Project Leader (Responsible Accountant) and Engagement Responsible in Adminflow – Roles and Special Logic

Overview

In Adminflow, each accounting firm can define its own project roles.

Two roles have special importance:

Project Leader (Responsible Accountant):

A standard project role with predefined permissions. Can be set as the “link role” connecting a project to a location, department, or team.

Engagement Responsible:

Has special logic and additional behavior beyond normal permissions (see below).


Can we rename the roles?

Yes. You can rename these roles (for example, “Client Manager” instead of “Project Leader”).

Changing the name does not change how the role behaves — the special logic follows the role itself, not the label.


Special behavior

Project Leader (Responsible Accountant)

  • No special behavior beyond the normal predefined permissions.
  • In Firm Settings, this role (or another one) can be chosen as the “link role” that connects projects with locations/departments/teams.
  • Default in quality control: Project Leader is preselected in quality control reports.
  • Change link role: The role that connects clients ↔ projects can be adjusted in Firm Settings (under “Other” or equivalent).


Engagement Responsible

  • AML notifications: Always receives AML due date and deadline notifications.
  • Task visibility: Can always see project tasks, even if they wouldn’t normally have access to that project.
  • Control: Automatically suggested as the controller for quality reviews and co-worker control.
  • Lists and integrations: Appears first in the client’s project list and is used in the HubSpot integration.
  • Change protection: Can only be changed by users with the Change Leaders permission.


How access works

  • From project → client: Any permissions you have on a project also apply at the client level.
  • From client → project: A client role does not automatically grant access to the client’s projects.
  • Global level: Access from a project or client does not automatically grant global access (for example, AML forms).


Team-based permissions

Some permissions only work when assigned to a team (not on project or client roles):

  • Projects in team/department – read/write
  • Send reminders

👉 Assign these permissions to the team role, otherwise they have no effect.


How to use the roles

  1. Open the project.
  2. Go to Roles.
  3. Assign Project Leader (Responsible Accountant), Engagement Responsible, and any additional roles.
  4. Save.

💡 Tip: Assign the Engagement Responsible early — this ensures AML notifications and control setup work correctly from the start.


Best practices

  • Clearly document internally what each role means and who should hold it.
  • Avoid conflicts: do not let the same person perform and control the same engagement.
  • Always make sure the correct person is set as Engagement Responsible (since this role always sees tasks and receives AML alerts).
  • Limit who can modify these roles — changing them requires the Change Leaders permission.


FAQ

Can we rename “Project Leader”?

Yes, renaming does not affect functionality.

Does a client role give access to its projects?

No, project access must be assigned separately.

Do project permissions apply to the client?

Yes, client-level access is the sum of all your project permissions.

What makes the Engagement Responsible special?

Receives AML alerts, always sees tasks, is suggested as the controller (including co-worker control), appears first in client lists, integrates with HubSpot, and can only be changed by users with the Change Leaders permission.



Oppdatert: 10/11/2025

Var denne artikkelen til hjelp?

Del tilbakemeldingen din

Avbryt

Takk skal du ha!