What I Built This Week: Perfex CRM Modules and Admin UX
This week I built two Perfex CRM modules and a wider Perfex CRM admin UX pass. It was not one big feature. It was a practical cleanup of the work that slows a CRM team down every day: finding the right context, filtering lists without remembering every field, scanning tables on mobile, and shipping module updates without guessing.
The important part is that I kept the work close to Perfex CRM instead of building a second system next to it. The new pieces are modules, hooks, list improvements, and release checks that fit into the existing admin workflow.
Core Idea: Keep Perfex Native, Make the Work Faster
the Perfex CRM admin layer already lives inside Perfex CRM, so the goal was not to replace Perfex. The goal was to remove friction around it.
A CRM usually gets messy in small ways. Tables become hard to scan. Email context sits outside the lead. Filters are powerful, but staff need to know the exact fields before they can use them. Mobile admin pages technically work, but they feel like desktop pages squeezed into a phone.
That is what I worked on this week. Two module builds mattered most: Email History and AI Filters.
What Changed in Practical Terms
The work breaks into four practical improvements: better customer context, faster CRM filtering, cleaner admin tables, and safer module releases. Email History handles the context problem. AI Filters handles the search and segmentation problem. The DataTables pass makes the daily admin screens easier to scan. The release gates reduce the risk of shipping a broken Perfex CRM module update.
For search, the main topic is Perfex CRM modules, but the real intent is broader: teams want CRM automation that does not leak data, break native workflows, or force staff to learn a new dashboard.
Module 1: Email History for Perfex CRM
The Email History module adds a read-only conversation view to Perfex leads and customers.
The module imports matching messages from configured IMAP mailboxes or from an .eml directory, then links messages only when the external participant exactly matches a lead or customer contact email in Perfex. That exact-match rule matters. It keeps the module useful without turning it into a loose email search index.
The module does not send mail, reply to mail, delete mail, or mark messages as read. It is built as evidence and context, not as another inbox.
For the lead screen, the useful part is simple: when I open a lead, I can see the latest accessible email context without leaving the CRM. The same context can also support next-step decisions in the lead profile. If a lead has gone quiet, if the newest email changes the status, or if the staff member needs a reminder of the last real conversation, the CRM view has the evidence nearby.
I also added stronger boundaries around internal mail. The module supports ignored same-domain email and additional internal company domains, so internal-only conversations do not pollute the customer history view. Existing audit data is not deleted just because visibility rules change.
The data handling is intentionally conservative. It stores plain text, participants, headers needed for the view, and the exact CRM relations. It does not store attachments, render HTML, load remote images, run tracking pixels, or show iframes. Credentials are encrypted, and imports can be dry-run first before applying changes.
That is the kind of CRM automation I trust more: read-only where it should be read-only, strict matching where loose matching would create noise, and enough auditability to understand what happened.
Module 2: AI Filters for Perfex CRM
The second module is AI Filters for Perfex CRM.
The idea is straightforward: a staff member describes the list they want in plain language, and the module converts that request into native Perfex filter rules.
This is useful because CRMs already have filtering logic, but users often do not remember where every field lives. They know what they want: overdue invoices, high-value leads from a source, active projects with a specific status, tickets that need attention. The module turns that intent into the existing filter system instead of inventing a separate search layer.
The safety boundary is the main feature. The module sends the user's request and the available filter definitions to OpenAI. It does not send the rows from the filtered list. It does not send saved filters as data. The model cannot return SQL, executable code, raw callbacks, or arbitrary column names. The server validates the output against an allowlist before applying anything.
The UI is also built around recovery. If the AI request fails, the user's current filter and typed text stay intact. Clearing the AI filter restores the exact pre-AI-filter state. The wand button is there for speed, but the result still lands inside Perfex's native filter behavior.
I also moved the module config into the native Perfex Settings area, added encrypted write-only API key handling, and tightened uninstall cleanup around role permissions. For release updates, the module checks immutable GitHub release assets, version metadata, SHA-256 digest, archive paths, PHP syntax, and same-filesystem swap behavior before replacing files.
That sounds boring until a CRM module update goes wrong. Then it is the only thing that matters.
Admin Lists Got the Biggest Visual Pass
The visible part of the week was the admin list UX.
I worked on a compact card-row skin for DataTables across the Perfex CRM admin layer. The point was to make list screens easier to scan without changing the underlying data source. Headers got cleaner sorting indicators. Active sort columns now show a stronger accent arrow, while unsorted columns keep a lighter hint. Row actions were compressed into a small menu where that made sense, and tag overflow now uses a +N pattern instead of stretching the row.
Leads got a stronger structure too. Status moved forward, contact actions became a clearer icon column, and source moved later where it belongs. This makes the table read more like a working queue instead of a raw database export.
I also fixed cache pain around admin CSS by using an md5-versioned custom.css URL. That was a small change with a big effect: immutable browser caching should not leave staff staring at an old stylesheet after a UX fix ships.
Mobile Admin Work
A CRM admin should not fall apart on a phone.
This week included mobile passes across clients, leads, projects, tasks, invoices, expenses, and estimates. I tightened key columns, touch targets, inputs, pagination contrast, right-edge scroll affordances, focus rings, and dark-mode behavior.
This is not about making a CRM feel like a consumer app. It is about making quick admin work possible when someone is away from a desk. If a user only needs to check a lead, scan an invoice, or update a task, the page should not punish them for opening it on mobile.
Knowledge Base Search Was Rebuilt
The knowledge base list also got a real search pass.
I added a central search hero, live count, highlighting, Enter and Escape behavior, and a keyboard shortcut. That turns the knowledge base from a static list into something closer to an internal tool. Staff should be able to find the right answer quickly, especially when they are already inside a customer workflow.
Lead Next Step Became More Useful
The lead next-step widget now has better context to work with. Email History can provide recent communication context, while the workflow keeps the decision close to the lead profile.
That is the direction I like for AI in CRM work. The AI should not float above the system. It should sit next to the actual record, use narrow context, explain the next action, and leave the user in control.
Release Gates and Tests Matter More Than the UI
The less visible work this week may be the most important.
I hardened module packaging and release gates, added checks around Email History migrations, tested importer behavior, covered AI Filters packaging, and added local TLS and deployment checks around the panel environment.
The lesson is simple: admin UX improvements are only credible when the release path is boring. A nice table skin is not enough if module updates are fragile. A useful AI filter is not enough if the model can push unsafe filter output. Email context is not enough if the module stores too much or links messages too loosely.
So the work was split between product surface and operational discipline: better screens, stricter modules, safer updates, and smaller failure modes.
What I Took From This Week
The best Perfex CRM customization is not the one that shows off the most custom code. It is the one that makes the existing CRM feel sharper without breaking the way teams already work.
Email History makes the CRM record more complete. AI Filters make the list views easier to use. The admin table work makes daily scanning faster. The mobile fixes make the same workflows less painful away from desktop. The release gates make the work safer to ship.
That is the version of AI CRM automation I want to keep building: narrow, useful, testable, and tied to real admin work.
