How to Track Multiple Visa Expiries Across UAE Entities Without Spreadsheets

Why visa tracking breaks the moment you cross entity lines

Picture a typical PRO firm in Dubai today. Their roster looks something like this: one mainland trading company in Bur Dubai with 50 employees on MOHRE work permits, a DMCC consultancy with 12 employees, two free zone outfits in JAFZA running 28 logistics staff between them, and a small ADGM-licensed advisory firm in Abu Dhabi with four senior executives. Five entities, four different licensing authorities, three immigration jurisdictions — and one very tired Excel sheet trying to hold the whole thing together.

For a single mainland company, a spreadsheet just about works. You can sort by expiry date, colour the next 30 days red, and stay on top of things if you are disciplined. But the moment you cross entity lines — different sponsors, different free zone authorities, different residency portals — that single sheet stops being a tracker and starts being a liability. The reason is not laziness. It is structural.

This article walks through why multi-entity visa tracking fails, what a unified expiry register actually looks like, and the operational pattern PRO firms use once they outgrow the spreadsheet.

The hidden complexity: visas live in different government systems

Before we talk about how to track UAE visas centrally, it helps to be precise about where they actually live. Each authority has its own portal, its own data model, and its own definition of "expiry."

For mainland companies, three federal and emirate-level bodies are involved:

• MOHRE issues the work permit, which has its own validity. This is the labour card that many firms still print and store separately from the residence visa.
• ICP (formerly ICA — the Federal Authority for Identity, Citizenship, Customs & Port Security) handles Emirates ID issuance for everyone and federal residency for the six emirates outside Dubai.
• GDRFA is Dubai-specific. If your sponsor is a Dubai mainland or Dubai free zone entity, the residence visa lives here, not on ICP's federal stack.

For free zones, the picture forks again. DMCC, JAFZA, RAKEZ, ADGM, Dubai South, DAFZ, Sharjah Media City, and dozens of others each operate their own member portal. Inside those portals you will typically find the establishment card, the labour card or e-channel equivalent, the visa, and sometimes the Emirates ID status — but the columns, statuses, and naming conventions differ between every zone. RAKEZ calls something a "transaction" that JAFZA calls a "request" and DMCC calls a "service application."

Then there are the regulators that sit on top: DED (Department of Economic Development) for the trade licence itself, KHDA for education, DHA for healthcare staff, RERA for real estate brokers. Any one of them can block a visa renewal even when the immigration paperwork is clean.

For a PRO firm with clients in three different free zones plus mainland exposure, the source-of-truth question becomes uncomfortable: which of the eight different portals is the authoritative date for each employee? If you do not have a single answer, you do not have a tracking system — you have a hope.

For a deeper breakdown of who does what, see our companion explainer on MOHRE, ICA, GDRFA, and DED.

The seven failure modes of spreadsheet-based expiry tracking

Most PRO firms have lived through every one of the following at least once. They are not edge cases — they are the reason firms eventually switch tools.

1. Stale formulas. Someone protects the date column with a formula referencing another tab. Six months later, a new joiner edits the source tab manually and the formula reference breaks silently. The cell still shows a date — just the wrong one.
2. Version forks via WhatsApp. A colleague on the road forwards "the latest tracker" over WhatsApp at 11pm. Three people now have three versions, each one slightly newer in different rows. The "latest" is whichever was opened last on someone's laptop.
3. Expired-but-no-one-saw. Conditional formatting turns a row red on day 30. But conditional formatting only fires when the file is open. A row can sit at zero days remaining for weeks if nobody opens the sheet on a Monday morning.
4. No audit trail when staff leave. When a PRO officer resigns, the firm inherits a folder of files but no record of why certain visas were marked "in progress." Decision context — which client said what, what the government officer requested — walks out of the door with the person.
5. Double data entry vs portals. Every renewal updates the government portal and the spreadsheet. Or it does not, and the two diverge. Reconciling them at year-end is a manual job that nobody volunteers for.
6. Shared drive permission rot. Three years in, the spreadsheet lives on a Google Drive folder where seven ex-employees still have edit access, two clients have view access by accident, and nobody is sure who can see what. Removing access without breaking links is its own multi-day project.
7. No alerting. This is the deepest one. A spreadsheet does not call you. It waits to be opened. The 30-day-before-expiry rule is fine in theory, but if everyone assumes someone else is checking, the rule is doing nothing. Real expiry tracking has to push, not be pulled.

Each of these failure modes is recoverable on its own. The problem is that they tend to compound — one stale formula plus one missed alert plus one ex-employee's account is the recipe for the AED 1,000 cumulative-fine cap that nobody saw coming.

What "good" looks like: a unified expiry register

If a spreadsheet is the wrong tool, what is the right shape of the data?

A unified expiry register is a single table — physically or logically — that holds every expiry-bearing record across every entity you manage, with the same fields for each row. The point is uniformity. A row for a DMCC consultant should have the same shape as a row for a mainland labourer, even though the underlying portals look nothing alike.

The minimum useful schema looks like this:

• Employee identifier — passport number is the only stable ID across all UAE systems; Emirates ID changes on renewal.
• Sponsor entity — which of your client companies sponsors this visa.
• Authority — MOHRE / ICP / GDRFA / specific free zone / DED, etc.
• Document type — work permit, residence visa, Emirates ID, labour card.
• Document number — the reference printed on the document itself.
• Issue date and expiry date — both, because some renewal windows are calculated forward from issue, not back from expiry.
• Renewal status — not started / documents collecting / submitted / under processing / completed.
• Owner — which PRO officer at your firm is responsible for this row right now.
• Last action and timestamp — the most recent state change, with who did it.

That last field is the audit trail. It is what a spreadsheet cannot give you, and it is what saves you when a client emails three months later asking "why was this visa late?" The answer is in the row, not in someone's memory.

Once every row has those nine fields, dashboards become trivial. You can group by client, by authority, by owner, by days-to-expiry. You can answer questions a spreadsheet never could — how many of my JAFZA clients have visas expiring in the next 60 days that have not started renewal? — in a single filter.

The same logic applies to all the documents your firm tracks beyond visas. We covered the broader pattern in Document Expiry Tracking: Best Practices for UAE PRO Firms — this article is the visa-specific, multi-entity sharpening of that idea.

Tiered alert architecture for multi-entity portfolios

A unified register tells you what is expiring. Tiered alerts decide who hears about it and when.

The mainstream pattern across well-run PRO firms is a four-tier alert ladder, with escalation built in:

• Day −90 (early notice): Notification to the PRO officer who owns the row. Action: open a renewal task, queue document collection from the client.
• Day −60 (status check): If the renewal task has not moved past "documents collecting", the alert escalates to the PRO officer's team lead. Action: chase the client directly.
• Day −30 (urgent): Alert lands with both the PRO officer and the firm's operations manager. Renewal must be in submission state by now, or there is a real problem.
• Day −14 (critical): Escalation to firm leadership. By this point, late renewal is on the table — fines, emergency processing, client conversation. This is not a routine PRO matter anymore.

For multi-entity portfolios, you also need a second axis: client tier. Your largest client deserves a 120-day early notice, not a 90-day one. Your smallest, simplest client may not need the 60-day intermediate tier at all. Hard-coded universal rules are the spreadsheet mindset; configurable per-client SLAs are how mature firms operate.

Two important design principles:

• Alerts should push, not be pulled. Email and in-app notifications, not a dashboard you have to remember to open. The Monday-morning ritual of opening the tracker is exactly what fails when someone is on holiday.
• Alerts should be actionable, not informational. "Visa X expires in 30 days" is not actionable. "Visa X expires in 30 days. Renewal task is unstarted. Click here to begin." is actionable. The alert should reduce cognitive load, not add to it.

The goal across both dimensions is that no one ever discovers an expiry by accident. Every expiry should be known about, owned, and worked on long before it becomes urgent.

The role-based access problem (and why it matters legally)

If you are a PRO firm handling visas for five different client companies, those five companies' visa data must not see each other. This sounds obvious. It is also exactly what spreadsheets cannot enforce.

Consider what happens in a typical multi-client tracker. Client A's HR contact emails for a status update on her own employees. Your PRO officer attaches the spreadsheet — the same spreadsheet that has Clients B, C, D, and E's data sitting on other tabs or other rows. Maybe filtered, maybe not. Either way, sensitive PII for four other clients has just left your firm in an email attachment.

Role-based access is the only way to make this structural rather than reliant on individual discipline. Concretely:

• Each client company's data is isolated at the tenant level, not the row-filter level.
• Internal staff are scoped by role: a junior PRO officer sees only their assigned clients; a partner sees the whole portfolio.
• Clients themselves see only their own employees, never anyone else's, even for a moment.
• Every access event is logged so you can reconstruct who saw what, when.

A spreadsheet has none of these. It has one access level — "open" — and one audit trail — "who last edited."

Building the workflow: how Proziyo solves this

This is the operational pattern Proziyo was built to make routine.

Every client company you onboard becomes its own isolated tenant in the platform. Their employee records, visa data, and document expiries live behind a hard tenant boundary — not a row filter, not a hidden tab. When your PRO officer pulls up Client A's dashboard, only Client A's data exists. Client B's data is not just hidden; it is structurally inaccessible from that view. This is enforced at the database layer using PostgreSQL row-level security, which means there is no application code path — accidental or otherwise — that can leak across the boundary.

On top of that isolation sits a unified expiry dashboard that aggregates across all your clients for your team's eyes only. A traffic-light view across MOHRE work permits, GDRFA residency visas, ICP-issued Emirates IDs, and free zone labour cards. Group by client, authority, document type, days-to-expiry, or owning PRO officer. Tiered alerts at 90, 60, 30, and 14 days are fired automatically — by email and in-app — to the assigned owner, with escalation to team leads if a task has stalled.

The audit trail is automatic too. Every status change, every document upload, every comment on a renewal task is logged with the actor, timestamp, and context. When a client asks three months later why something was late, the answer is one click away.

If you are at the point where one tracker spreadsheet has become five, and five has become unmanageable, start a 30-day free trial and rebuild the same workflow with the structure it needs. Or visit our features page or visa processing solution to see the workflow in detail. We have onboarded firms with hundreds of employees across a dozen entities in under a week.