Engineering and architecture
Unanet AE data: project, CRM and resource records
By SourceX Editorial · Updated
Short answer
Unanet AE data covers three linked record families: CRM pursuits and proposals, projects with budgets, time and invoices, and resource plans. The most useful exports keep the chain from pursuit to project to invoice intact through shared IDs. Client contact data is the main exception: exclude it or reduce it before anything leaves the firm.
Key takeaways
- The value of Unanet AE data sits in its links: opportunity to project number, phase to timesheet, budget to invoice.
- Export code tables and a short data dictionary with the records, or the joins cannot be rebuilt later.
- CRM contact records hold personal data about client staff and are usually excluded or reduced to company-level attributes.
- Replace employee and client identifiers with stable pseudonyms instead of dropping them, so records stay linkable.
What records does a Unanet AE firm hold?#
A firm on Unanet AE typically holds three families of records: pursuit records in the CRM, delivery records in project accounting, and staffing records in resource planning. Each is useful on its own for running the firm. Linked together, they describe how the firm wins work, plans it, staffs it and gets paid.
COOs usually meet this data at a trigger point: a migration from Deltek Vision or Ajera, an acquisition that brings a second Unanet instance, or a review of which years of history are worth keeping. The same inventory serves all three.
Editions, hosting and configuration differ between firms, so field names and export routes here are described generally. Confirm specifics with your Unanet administrator and the vendor's current documentation.
Unanet AE record families and what they link to#
Unanet AE record families matter less as separate tables than as a connected chain. The table lists the common families, what they link to and the usual licensing position if the firm ever reviews them for outside use.
| Record family | Typical records | Links to | Licensing note |
|---|---|---|---|
| Opportunities and pursuits | Stage history, go or no-go decisions, win and loss reasons, competitors noted | Proposal, then project number when won | Strong candidate once client names are generalized |
| Proposals and qualifications | Scope narratives, fee approaches, team selections, resumes used | Opportunity record | Resumes and staff bios need personal data handling |
| Contacts and companies | Client staff names, titles, emails, phone numbers, relationship notes | Opportunities and projects | Usually excluded or reduced to company type and sector |
| Projects, phases and tasks | Work breakdown, contract type, fee, status changes | Opportunity, timesheets, invoices | Core of any package |
| Budgets and forecasts | Original budget, revisions, estimate at completion | Project phases | Shows how plans changed against reality |
| Timesheets and expenses | Hours by person, phase and labor category, with notes | Projects and employees | Pseudonymize people and review notes for client detail |
| Resource plans | Planned assignments, utilization targets, conflicts | Projects and employees | Aggregate or pseudonymize |
| Invoices and receivables | Billing, write-offs, collection history | Projects and clients | Commercially sensitive and often generalized |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Why the pursuit-to-invoice chain matters#
The pursuit-to-invoice chain matters because outcomes give operational records their meaning. A go or no-go note is a judgment; whether the project was won, overran its budget or ended in a write-off is the result of that judgment. Records carrying both are far more useful than either alone, for the firm's own analysis and for AI developers studying how professional services decisions play out.
A stable pseudonym keeps a record linkable without saying who it was. Dropping identifiers outright breaks the joins and leaves a pile of disconnected tables. Keep these keys intact in every export:
- Opportunity ID to project number, including lost pursuits that never became projects.
- Project number to phase and task codes, with the code table that explains them.
- Phase codes to timesheet lines, budget revisions and invoice lines.
- Employee IDs, replaced by stable pseudonyms rather than removed.
- Client IDs, replaced by stable pseudonyms plus a sector or client type field.
- Dates for every stage change, so durations can be measured without guessing.
Client contact data in Unanet CRM#
Client contact data is the record family that needs the most caution in a Unanet AE export. CRM contacts hold names, titles, emails, phone numbers and relationship notes about individual people at client organizations, and those notes are sometimes candid. Privacy laws such as CCPA may apply depending on who the contacts are, and that assessment belongs with counsel, deal by deal.
The practical default is to exclude contact records and keep only company-level attributes such as sector, size band and region on each opportunity. Free-text fields in opportunities and activities also name people, so they need review or redaction even when the contact table is left out.
If pursuit history was carried over from an earlier setup, such as a legacy Cosential database or another AEC CRM, check how contacts and activities were mapped. Legacy notes often arrive in a single text field, mixing names, phone numbers and pursuit strategy in one block.
Exporting Unanet AE data without losing the links#
Exporting Unanet AE data well is mostly about planning the joins before pulling any report. Many firms start with saved reports and exports inside the application; firms with larger archives or on-premises deployments may have database or API access. Which route applies depends on deployment and agreement, so check with Unanet and your administrator.
| Export step | What to capture | Common mistake |
|---|---|---|
| Define scope | Date range and project status, such as projects closed in a set period | Pulling everything and sorting later |
| Export record families | Internal IDs alongside display names | Exporting names only, which breaks joins |
| Export code tables | Phases, labor categories, organizations, opportunity stages, loss reasons | Assuming codes are self-explanatory |
| Write a data dictionary | Field meanings and firm-specific conventions | Relying on one controller's memory |
| Test the joins | A few projects rebuilt end to end from the exports | Discovering gaps after access ends |
| Store read-only | Export date, method and person responsible | Overwriting exports with later pulls |
Resource and staff records: what to keep and what to leave out#
Resource records in Unanet AE show how a firm matched people to work: who was planned on which phase, how plans shifted when a pursuit was won, and where utilization targets met reality. That planning-versus-actual pattern is the useful part, and it survives pseudonymization well.
Keep labor category, discipline, office and seniority band against each pseudonymized person, because those attributes explain staffing decisions without naming anyone. Leave out salaries, cost rates tied to individuals, performance notes, leave records and anything from HR modules. Employee notices and any applicable employment or privacy rules should be checked with counsel before staff records are reviewed for outside use.
Resumes attached to proposals are a separate case. They name people and describe their careers in detail, so they are usually excluded, with the proposal keeping only the role and discipline each team member filled.
Illustrative: an engineering firm inherits a second Unanet instance#
Illustrative: a fictional MEP engineering firm acquires a smaller civil firm, and both run Unanet AE with different phase structures and CRM stages. The COO needs a consolidated view of pursuit and delivery history before the acquired instance is retired.
The team exports both instances with IDs and code tables, maps the acquired firm's phases to its own and keeps the original codes beside the mapped ones. Contact records are excluded, and opportunities keep sector and region. When the firm later reviews the combined archive for data licensing, the chain from opportunity to final invoice is already documented, and employees appear only as stable pseudonyms with labor category.
How SourceX works with Unanet AE records#
SourceX begins with a metadata-only fit check: which Unanet modules the firm uses, years of history, record families and known restrictions. No exports are requested at that stage. If the firm proceeds, the SourceX five-step transaction of Supply, Rights, Preparation, Approval and Delivery governs everything after, and the firm approves each step.
Contact exclusions, pseudonymization rules and client restrictions are recorded in the SourceX Evidence Packet together with provenance, licensing rights, permitted use, the privacy record and release authorization.
Frequently asked questions
Are timesheet notes useful or risky?
Both. Timesheet notes often explain what work was done and why a phase ran over, which is valuable context. They also mention client staff, project addresses and sometimes personal matters. Run them through a de-identification pass with a human check rather than keeping or dropping them wholesale.
Should lost pursuits be included?
Yes, where rights allow. Lost pursuits are half of the go or no-go story; without them, any analysis sees only the work the firm won. Keep the loss reason and stage history, and generalize client and competitor names.
Can billing rates and salaries be part of a package?
Salaries and HR fields are normally excluded. Billing rates and fees are commercially sensitive and are usually generalized, banded or expressed relative to budget. The useful signal is often how actual effort compared with plan, not the currency amounts.
What if we are migrating off Unanet?
Export full history with IDs and code tables before access ends, even if the new system receives only open projects. A migration that carries only active work drops the closed history, which is where the outcomes live.
Do project managers need to be involved?
For the data dictionary, yes. Project managers and controllers know what firm-specific phases, status codes and note conventions meant in practice. A short interview with a few long-serving people prevents years of records from being misread.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.