The agency arc explained who may act for a taxpayer; this lesson explains what exactly each actor may do. In the Self-Service Portal, that question is answered by roles — named bundles of permissions that a taxpayer attaches to each assignee or assigned tax agent. The procedural home is the Roles page of the Assignee Management module, confirmed from the local SSP External Guide: "Roles — set the access permissions that can be granted to assignees. Typical roles: read-only viewer, return preparer, return submitter, payment authoriser." The companion rules are equally concrete: assignees are registered, searched, viewed, edited, deactivated and removed on the Assignees page; tax agents receive predefined roles via Tax Agent Assignment; the visible module menu changes with the session ("all modules available subject to user role"); and the hygiene trio — "review the assignees list at least quarterly, restrict permissions to the minimum needed, and never share an SSP user account between people" — is stated in terms in the guide.

The legal framework is richer than beginners expect, because the Income Tax Act [Chapter 23:06] contains an entire electronic-administration code — Part VIIIA, Sections 80B–80L (inserted by the Finance Act 12 of 2006 w.e.f. 1 January 2007) — that maps almost one-to-one onto the SSP's role architecture, and every provision below is confirmed verbatim from the 27 May 2025 source Act. Section 80E prescribes the user agreement between ZIMRA and registered users, which must cover the allocation of digital signatures, the user's duty to "ensure the security of the digital signatures allocated to them", ZIMRA's access for verification and audit, and electronic record-keeping. Section 80F governs registration of registered users: no person may communicate with the Commissioner through the system unless registered (Section 80F(1)); approval depends on the applicant introducing "adequate measures to prevent disclosure of the digital signature … to any person not authorised to affix such signature" and to safeguard data integrity (Section 80F(3)); and registration may be suspended or cancelled on grounds (a)–(h) — breach of the user agreement, false statements, non-use, contravention of the Act, conviction (including offences of dishonesty), sequestration/liquidation, cessation of business — but only after notice, reasons and "a reasonable opportunity to respond" (Section 80F(5), the audi alteram partem safeguard). Section 80G requires every digital signature to be "unique to the registered user and under the sole control of the registered user", verifiable, and integrity-linked so that tampering invalidates it — and, critically for this lesson, obliges the Commissioner to allocate signatures "for the user and each employee of the user nominated in the user agreement" (Section 80G(2)): the statute itself contemplates per-person credentials inside one organisation, which is exactly what the role system operationalises. Section 80J then supplies the liability architecture: a user whose signature is compromised must tell the Commissioner "without delay" (Section 80J(1)); until that notification, ZIMRA "shall be entitled to assume" that data signed with the signature came with the user's authority (Section 80J(2)); and in any proceedings it is presumed, in the absence of proof to the contrary, that the signature was used with the consent and authority of the registered user (Section 80J(3)). Section 80K preserves paper fallback when systems are down, and Section 80L criminalises unauthorised use of another's digital signature and electronic falsification at level 12 / ten years' imprisonment.

Read together, the statute and the SSP say the same thing from two directions. The law says: credentials are personal, their security is your duty, and what is done under them is yours until you prove otherwise. The system says: give each human their own login, give each login only the role it needs, and review the grant book quarterly. This lesson builds the standard role taxonomy (viewer / preparer / submitter / payment authoriser) into a segregation-of-duties design for each taxpayer size, pairs it with the two-deep submission rule from earlier lessons, and works through scenarios — the owner-operator who holds everything, the SME splitting preparer from submitter, the corporate treasury enforcing maker-checker on payments, and the fraud post-mortem in which Section 80J(3) decides who carries a rogue submission. Case law on the SSP role system is absent (stated honestly); Hilmax Enterprises 22-HH-832 and the Part VIIIA framework supply the nearest litigated terrain. Screen-level specifics beyond the guide's confirmed text are flagged for verification against the SSP help.

Every accounting student learns segregation of duties: the person who records a transaction should not be the person who approves payment, and no single person should control a process end-to-end. TaRMS hard-codes that doctrine into tax compliance. A role is the unit of trust the system understands — a bundle of permissions saying this login may see, this login may build, this login may bind, this login may pay. The taxpayer composes its control environment by deciding which humans hold which bundles.

Why a whole lesson? Because the stakes of the composition are statutory, not merely managerial:

• A login with submission rights can create an assessment: under Section 37A(10)–(11) the filed return is the assessment, and under Section 37(6)–(7) it binds the taxpayer and its signatory (Assigning an Agent lesson).
• A login with payment rights moves money from bank to Single Account — and the bank-details/withdrawal cluster was flagged as the fraud-sensitive zone in the Taxpayer Profile lesson.
• Every login is, in the statute's language, a digital signature matter: personal (Section 80G(1)(a) "unique … and under the sole control"), reportable on compromise (Section 80J(1)), and presumptively authorised in everything done under it (Section 80J(3)).

So the role grid is where three earlier threads converge: the attribution chain (Section 5 secrecy; Sections 53–61 answerability; one-person-one-login from the Logging In lesson), the continuity doctrine (two-deep submission; quarterly sweep from the User Profile lesson), and the agency arc (assignees and agents receiving exactly scoped grants). This lesson is the design manual.

Part VIIIA (Sections 80B–80L, inserted by the Finance Act 12 of 2006 w.e.f. 1 January 2007) regulates "communication through a computer system" established by the Commissioner under Section 80D — the statutory platform on which Section 80DD later erected the Virtual Tax Management System, TaRMS itself (Finance Act 1 of 2018; see the technology lesson in the debt course). The provisions that govern users, credentials and authority:

B.1 Section 80E — the user agreement

The Commissioner may prescribe a user agreement between ZIMRA and registered users covering: terms of use of specified equipment and facilities; "the allocation to a registered user of a digital signature by the Commissioner"; "the requirement that registered users ensure the security of the digital signatures allocated to them in the manner specified in the agreement"; the manner of affixing signatures; ZIMRA's "reasonable access to the computer system of the registered user … for such verification and audit purposes as may be required"; and the manner and period of keeping electronic records. Note the audit-access clause: by contracting into the e-system, the user grants ZIMRA a window into its own systems — a point practices should brief clients on.

B.2 Section 80F — registration, and the suspension/cancellation regime

• Section 80F(1): "No person shall communicate with the Commissioner through a computer system … unless such person is a registered user." Electronic filing is a privilege of registration, not an open channel.
• Section 80F(2): application in prescribed form + completed user agreement + prescribed fee (if any) + supporting information.
• Section 80F(3): approval criteria — the Commissioner must be satisfied the applicant (a) "will make regular use" of the system; (b) "will introduce adequate measures to (i) prevent disclosure of the digital signature allocated to him or her to any person not authorised to affix such signature; (ii) safeguard the integrity of information communicated"; and (c) will maintain the reliability standard of his own computer system per the user agreement. The role-and-permission discipline this lesson teaches is the "adequate measures" the statute demands — a sloppily shared login is not just bad practice; it is a breach of the registration criteria.
• Section 80F(4): suspension or cancellation grounds: (a) non-compliance with the user agreement or registration conditions; (b) false or misleading statements, or material omissions, in the application; (c) failure to make regular use of the system; (d) contravention of the Act; (e) conviction of an offence under the Act; (f) conviction of an offence involving dishonesty; (g) sequestration or liquidation; (h) no longer carrying on the business for which registration was issued.
• Section 80F(5): before cancelling or suspending, the Commissioner shall give notice, provide reasons, and afford "a reasonable opportunity to respond and make representations" — administrative-justice protection built into the section.

B.3 Section 80FF — compulsory e-registration

Inserted by the Finance Act 2 of 2017 (gazetted 23 March 2017, backdated to 1 January 2017): the Commissioner may, by written notice, require any taxpayer who renders a self-assessment return to become a registered user. As noted in the debt-technology lesson, non-compliance attracts the civil penalty of US$1,000 per day up to 181 days (Section 80FF(4)), itself a debt due to ZIMRA. In the TaRMS era this is the provision that makes portal use effectively mandatory for the self-assessing population.

B.4 Section 80G — digital signatures: personal by statute

Every digital signature must (Section 80G(1)): (a) "be unique to the registered user and under the sole control of the registered user"; (b) be capable of verification; (c) be linked to the transmitted data so that compromise of integrity invalidates the signature; (d) conform to the Commissioner's prescriptions in the user agreement. And Section 80G(2): on registering a user, the Commissioner allocates — for a natural person, a signature (or sufficient signatures for the user "and each employee of the user nominated in the user agreement"); for a non-natural person, "sufficient digital signatures for each employee of the user nominated in the user agreement". The statute thus expects an organisation to nominate individual humans, each with an individually controlled credential — the legal ancestor of the SSP's per-person accounts and the reason "role accounts" and shared logins are anathema.

B.5 Section 80J — the liability triangle

• Section 80J(1): on compromise of a signature's security, the user must inform the Commissioner in writing "without delay".
• Section 80J(2): no liability attaches to ZIMRA for the user's security failures; where signed data is received "(a) without the authority of the registered user … and (b) before notification … that the security of the digital signature … has been compromised", ZIMRA "shall be entitled to assume that such data has been communicated by, or with the authority of, the registered user".
• Section 80J(3): in any proceedings, prosecution or dispute, "it shall be presumed, in the absence of proof to the contrary, that such signature was so used with the consent and authority of the registered user".

This is the statutory spine of every scenario in this lesson: what happens under your credential is yours, unless and until you (i) prove the contrary and (ii) — for prospective protection — notified the compromise without delay. The notification duty converts credential hygiene from prudence into obligation.

B.6 Section 80K and Section 80L — fallback and offences

Section 80K: when the system (ZIMRA's or the user's) is inoperative, the parties revert to written communication "in the manner prescribed in this Act" — deadlines are met on paper, not missed (Section 80K(1)); and the Commissioner may always demand original documents (Section 80K(2)). Section 80L: using another's digital signature without authority (Section 80L(1)), or making/falsifying electronic records or dishonestly affixing signatures (Section 80L(2)), is an offence punishable by a fine up to level twelve or imprisonment up to ten years or both — among the heaviest sanctions in the Act, signalling how seriously Parliament treats credential integrity.

B.7 The general-law overlay

The role system also serves provisions met throughout the course: Section 5 secrecy (minimum-necessary access is the only defensible reading of "preservation of secrecy" inside a firm); Sections 53–61 (representative taxpayers and the public officer — the humans the law holds answerable need visibility commensurate with their answerability); Section 37(5)–(7) and Section 37A(10)–(11) (authority and attribution of returns); and the engagement/assignment doctrine from the previous lesson (paper and grant as twins).

C.1 The standard role taxonomy

The guide's four "typical roles" form an escalating ladder of power. Build intuition for each:

1. Read-only viewer. Sees balances, returns, notices; changes nothing. The natural grant for: an owner monitoring an outsourced function, a parent company's CFO watching a subsidiary, an auditor during fieldwork, a junior in training. Cost of over-granting: confidentiality only — but recall Section 5 makes even seeing tax information a guarded privilege; viewers should still be minimum-necessary.
2. Return preparer. Builds returns, populates fields, uploads attachments, saves drafts — but cannot bind the taxpayer. The maker in maker-checker. A preparer's half-finished work lives in Drafts, and the standing doctrine applies: a draft discharges nothing (Taxpayer Profile lesson) — preparer output is inert until a submitter acts.
3. Return submitter. Presses Submit: the act that, via Section 37A(10)–(11), creates the assessment and, via Section 37(6)–(7), binds taxpayer and signatory. The checker. This is the role the two-deep rule counts: at least two submission-capable humans per taxpayer at all times (Logging In lesson), because a deadline with zero available submitters is a penalty already accruing.
4. Payment authoriser. Moves money — initiates payments to the Single Account (Payments → New Payment) and stands nearest the fraud-sensitive cluster (bank details, withdrawals — Taxpayer Profile lesson). The strongest candidate for separation from everything else: the person who files should ideally not be the person who pays, and neither should control changes to banking details alone.

C.2 Composing the grid: three sizes, three designs

The owner-operator (no staff). One human inevitably holds all four roles. The design answer is not separation (impossible) but compensating controls: the two-deep rule satisfied by a trusted second (spouse-director, external agent) holding dormant submitter rights; bank-detail changes verified against the profile before any withdrawal; and the owner's own credential hygiene treated as the entire control environment — because Section 80J(3) means anything done under that login is presumptively the owner's act.

The SME with a small finance function. The classic grid: bookkeeper = preparer; accountant or external agent = submitter; owner/director = payment authoriser + dormant submitter. Maker-checker on returns (preparer ≠ submitter), money separated from filing, redundancy on submission. Quarterly review confirms the grid still matches the org chart.

The corporate / group. Add: per-entity grants (a group shared-services accountant holds preparer across ten TINs but submitter on none); treasury holds payment authorisation under its own dual-control conventions; the public officer (Section 61) holds visibility over everything she is answerable for — a viewer-or-better grant on every head; and the external agent's predefined bundle is scoped per the engagement (Assigning an Agent lesson). Joiners-movers-leavers feed the grant book the day HR moves, not at quarter-end — though the quarterly sweep remains the backstop.

C.3 Power and visibility: the menu follows the role

The guide confirms the mechanism: after shifting into a taxpayer, "all modules [are] available subject to user role". A preparer may see Tax Return Management but not Payments; a viewer sees reports but no Submit buttons. Two practice consequences. First, test after granting (the step-4 discipline from the previous lesson): the only proof a role is right is a login that sees what it should and cannot do what it should not. Second, diagnose access complaints through roles before suspecting faults: "I can't see the payment page" usually means the grant, not the portal.

C.4 The credential-compromise drill

Because Section 80J(2) protects ZIMRA only until notification, and Section 80J(3) presumes authority absent proof to the contrary, the response to any suspected compromise is a fixed sequence: (1) contain — change the password (Getting Started → Changing the Password) or force reset; (2) notify ZIMRA in writing without delay — Section 80J(1) is a duty, and the notification is also the act that stops the Section 80J(2) assumption running forward; (3) review what was done under the credential (Submitted Tax Returns; payment history; profile-change applications — the "unexplained contact change = incident" drill from the User Profile lesson); (4) revoke or re-scope grants that enabled the exposure; (5) document everything — the contemporaneous record is the "proof to the contrary" that Section 80J(3) invites. A taxpayer who skips step 2 has, by statute, adopted whatever the intruder filed until it can affirmatively disprove authority.

C.5 Why the statute presumes against you — and why that is good design

Beginners bristle at Section 80J(3): why should the victim of credential theft carry a presumption? Because the alternative destroys the system. If "that wasn't me" were a free defence, every inconvenient return, every admission-laden declaration, could be disowned after the fact, and electronic filing would prove nothing. The presumption is rebuttable — proof to the contrary displaces it — and the statute pairs it with tools squarely in the user's control: sole-control signatures (Section 80G(1)(a)), nominated per-employee credentials (Section 80G(2)), the security-measures registration criterion (Section 80F(3)(b)), and the without-delay notification valve (Section 80J(1)). The design message of Part VIIIA, and of this whole lesson: the law gives you the apparatus to make "who did what" provable, then holds you to the record that apparatus produces.

D.1 The sole trader's compensating controls (individual)

Tendai, a Bulawayo electrician (sole trader, income tax + presumptive considerations aside), holds all roles himself. Implementation: his accountant sister holds a dormant submitter grant (two-deep); his phone and email on the SSP profile are current (recovery anchor — Password lesson); he checks his Summary Report monthly so an unauthorised payment or filing would surface within 30 days; and he knows the compromise drill. Cost: nothing. Benefit: when he was hospitalised in March, his sister filed the QPD-supporting return on 24 March — one day before the 25 March instalment date (Section 72) — under her own login, exactly as the architecture intends.

D.2 The SME maker-checker in action (SME)

Pamberi Hardware (Pvt) Ltd runs the classic grid (C.2). February's VAT 7: the bookkeeper (preparer) builds the return and uploads the input-tax schedule on the 18th; it sits in Drafts; the external agent (submitter) reviews on the 20th, catches a double-counted credit note — USD 1,840 of input tax that would have been over-claimed — corrects, and submits; the owner (payment authoriser) pays the corrected liability. Had one person held preparer + submitter, the error files, and the cure costs an amendment plus exposure to Section 46 additional tax on the difference if ZIMRA finds it first (up to 100% of the tax difference; Section 46(6) remission only where no intent to evade). The grid is cheaper than the cure.

D.3 The rogue-submission post-mortem (large corporate)

Mashonaland Breweries Ltd discovers a fraudulent withdrawal application lodged from a payroll clerk's login that — contrary to design — still carried a payment-related role from a previous job rotation. The post-mortem through the statutory lens: the company (registered user with nominated employees, Section 80G(2)) cannot point to ZIMRA — Section 80J(2) excludes ZIMRA's liability and entitled it to act on the signed application received before any compromise notice. Internally, the Section 80J(3) presumption fixes the act on the clerk's credential; whether the clerk or an impersonator acted is the company's evidentiary problem. The control failures are textbook: a mover's grant not re-scoped (joiners-movers-leavers), no dual control on the withdrawal cluster, and the quarterly review missed. The remediation list writes itself — and note the criminal dimension: if a colleague used the clerk's credential, that is a Section 80L(1) offence (level 12 / ten years).

D.4 The agent practice as registered user (professional)

Rudo's firm, filing for sixty clients, is itself the registered-user side of sixty user agreements' worth of trust. Her obligations under Section 80F(3)(b) (adequate measures), Section 80G (per-employee signatures for staff "nominated in the user agreement"), and Section 80J(1) (report compromise without delay) are registration conditions — breach risks Section 80F(4) suspension or cancellation of her e-registration, which would disable her practice wholesale (subject to the Section 80F(5) hearing). Her internal grid mirrors what she builds for clients: juniors prepare, two seniors submit, no client payment authority held at all (clients pay their own liabilities), and a standing instruction that any staff departure triggers same-day grant revocation across all sixty client assignments.

Stated honestly: no reported Zimbabwean case in the source materials deals with SSP roles, permissions or the Section 80J presumptions. Part VIIIA's nearest litigated neighbour in the source annotations is Hilmax Enterprises (Pvt) Ltd v ZIMRA 22-HH-832 (annotated to Section 44: ZIMRA's entitlement is to information, not the taxpayer's laptop — met in the Administration lesson), which illustrates judicial willingness to police the boundaries of ZIMRA's electronic-era powers. PIL v ZIMRA 17-HH-213 (annotated to Section 80C in the debt-technology lesson) confirms electronic data's admissibility with due weight — the evidentiary premise on which role-based attribution matters at all. The self-assessment line (CF 18-HH-099; Nestlé 20-SC-290/23-HH-312) supplies the stakes: what a submitter files binds. Beyond these, the area is governed by the statute itself; no authority is invented to fill the gap, and foreign electronic-signature jurisprudence is noted only as persuasive colour (the source editor's note to Section 80G itself remarks on a Canadian "thumbs-up emoji" signature ruling — an editorial aside, not Zimbabwean law).

1. One login to rule them all. A single shared "accounts@" login violates the guide's express rule, fails the Section 80F(3)(b) "adequate measures" criterion, collapses Section 80J(3) attribution into one undifferentiated identity, and converts every staff departure into a full credential rotation. Per-human accounts, per-human roles — the statute (Section 80G(2)) has expected it since 2007.
2. Granting by convenience, not design. "Just give her everything so she can work" creates submitter-payment combinations that no auditor would pass in a bank and no taxpayer should run in TaRMS. Grant the minimum; escalate deliberately.
3. Movers keeping old roles. Leavers get revoked; movers get forgotten. Role review must follow every internal transfer — the rogue-submission scenario in D.3 is a mover story, not a hacker story.
4. Zero or one submitter. Over-tight grids fail the other way: a lone submitter's leave, lock-out or licence lapse is a deadline default in waiting. Two-deep, always — and test the second login quarterly (the "double-stale" failure from the User Profile lesson).
5. Silent response to compromise. Changing the password and saying nothing leaves the Section 80J(2) assumption running and the Section 80J(1) duty breached. Notify ZIMRA in writing without delay; the letter is cheap, the presumption is not.
6. Treating Drafts as progress. Preparer output discharges nothing. Deadline dashboards must track submitted status, not "the bookkeeper says it's done".
7. Forgetting the paper fallback. When the portal is down on deadline day, Section 80K(1) prescribes written communication — downtime is not a defence for doing nothing. Keep the manual-filing route in the practice runbook.
8. Ignoring the e-registration's own fragility. Suspension/cancellation grounds (Section 80F(4)) include contravention of the Act and dishonesty convictions; a practice or corporate that treats e-registration as unconditional infrastructure has not read the section. The Section 80F(5) hearing right is the safety net — but the grant book is the prevention.

Work through the questions one at a time. Choose an answer and it is graded immediately, with an explanation and the provision it comes from. Your progress is saved, so you can stop and resume.

• Roles are the SSP's segregation-of-duties engine: viewer / preparer / submitter / payment authoriser (guide, confirmed), with the module menu itself shaped "subject to user role".
• Part VIIIA is the legal substrate, confirmed verbatim: user agreements (Section 80E), registration with security-measures criteria and a noticed, reasoned, heard suspension/cancellation regime (Section 80F(3)–(5)), compulsory e-registration on notice (Section 80FF), personal sole-control digital signatures allocated per nominated employee (Section 80G), the compromise-notification duty and the authority assumption/presumption (Section 80J(1)–(3)), paper fallback (Section 80K), and level-12/ten-year offences for credential abuse (Section 80L).
• What happens under your credential is presumptively yours (Section 80J(3)); the rebuttal is built from the hygiene this course keeps teaching — per-person logins, scoped roles, tested backups, contemporaneous incident records, and the without-delay notice.
• Design by size: owner-operators compensate (dormant second submitter, monthly Summary Report check); SMEs run maker-checker (preparer ≠ submitter; payments separate); corporates add per-entity scoping, treasury dual control, public-officer visibility, and joiners-movers-leavers discipline.
• Two-deep submission and the quarterly review are the load-bearing habits; movers, not leavers, are the audit finding waiting to happen.
• Drafts discharge nothing; downtime excuses nothing (Section 80K paper fallback).
• No case law on the role system (stated honestly); Hilmax and PIL mark the litigated edges of the electronic regime. Role names, granularity and the tax-agent predefined bundles are flagged .

The four typical roles

The Section 80J liability triangle

flowchart TD
 A[New person needs access to a taxpayer] --> B{Own SSP account?}
 B -->|No| C[Sign up first - never share credentials Section 80G]
 B -->|Yes| D{What must they DO?}
 C --> D
 D -->|Only see| E[Viewer]
 D -->|Build returns| F[Preparer]
 D -->|Bind the taxpayer| G[Submitter - count toward two-deep]
 D -->|Move money| H[Payment authoriser - dual control]
 E --> I[Grant minimum role; test the login]
 F --> I
 G --> I
 H --> I
 I --> J[Quarterly review: leavers removed, movers re-scoped, backups tested]
 J --> K{Compromise suspected?}
 K -->|Yes| L[Contain → notify ZIMRA without delay Section 80J 1 → review acts → re-scope → document]
 K -->|No| J

Statutes & sections

• Income Tax Act [Chapter 23:06], Part VIIIA (inserted Finance Act 12 of 2006 w.e.f. 1 Jan 2007) — Section 80E (user agreements: signature allocation, security duty, ZIMRA verification/audit access, e-records); Section 80F (registered users: exclusivity (1); application (2); approval criteria incl. measures preventing unauthorised signature use (3); suspension/cancellation grounds (a)–(h) (4); notice-reasons-hearing safeguard (5)); Section 80FF (compulsory e-registration on notice; Finance Act 2 of 2017 backdated 1 Jan 2017; US$1,000/day civil penalty ≤181 days per Section 80FF(4)); Section 80G (digital signatures: unique, sole control, verifiable, integrity-linked (1); allocation per nominated employee (2)); Section 80H (electronic retention satisfies record duties); Section 80J (compromise notification without delay (1); ZIMRA's authority assumption pre-notification (2); presumption of consent and authority absent contrary proof (3)); Section 80K (written-communication fallback; originals on demand); Section 80L (unauthorised signature use; electronic falsification — level 12 / 10 years). Supporting: Section 5 (secrecy); Section 37(5)–(7), Section 37A(10)–(11) (authority and attribution); Section 44 (information powers); Section 46 (additional tax); Section 61 (public officer); Section 72 (QPDs).

Case law

• None on roles/permissions or Section 80J — stated honestly. Adjacent: Hilmax Enterprises (Pvt) Ltd v ZIMRA 22-HH-832 (Section 44 — information, not the laptop); PIL v ZIMRA 17-HH-213 (Section 80C — electronic data admissible with due weight); self-assessment line (CF 18-HH-099; Nestlé 20-SC-290/23-HH-312) for the stakes of submission. Editor's note to Section 80G references foreign electronic-signature developments (persuasive colour only, non-binding).

ZIMRA guidance

• Comprehensive Guide to the ZIMRA Self-Service Portal (local External Guide) — Assignee Management: Roles page ("typical roles: read-only viewer, return preparer, return submitter, payment authoriser"), Assignees page verbs, Tax Agent Assignment predefined roles; permissions hygiene (quarterly review, minimum permissions, no shared accounts); module availability "subject to user role". Official SSP online help (https://mytaxselfservice.zimra.co.zw/help/ssp/en/default.htm) unreachable this run — exact role names, granularity, custom-role capability and predefined agent bundles flagged .