AI Development and Agentic Automation Projects

The automation that raises sales process tasks had raised the same one twice, seconds apart. Each of its eighteen checks looks for an existing task and then creates one if it finds none, which is a question rather than a rule, and two runs happening at once both pass it.

• The run history settled it. Two runs that overlapped produced both duplicate pairs, and a third run seconds later, which overlapped nothing, produced exactly one task. The gap that had looked like a coincidence was the gap that let the earlier runs finish.
• The obvious remedy is to make the automation run one at a time. That setting was written into the live definition, read back correctly, and survived switching the automation off and on. Runs kept overlapping anyway. Every check except the one that looked at the outcome would have reported this as done.
• A later test carried the more useful finding. Seven genuinely overlapping runs produced seven tasks and no duplicates at all, so overlapping is necessary but not sufficient, and the fault is intermittent rather than systematic. That argued against building an automation that deletes tasks.
• What shipped instead is a report. It reads only, follows every page rather than the first, and separates a real collision from ordinary test leftovers by whether the copies appeared in the same second. Its first run found an open pair that nobody had noticed.

The sales process expects an awareness call and then a discovery call. On a smaller account both can happen in a single sitting, and the process had no way to record that. The lead stopped at a step the work had already satisfied.

• The satisfying logic already existed and nothing about the process changed. An appointment marked as the discovery booking ticks the booking step when it is created and the call step when it is closed, so one appointment covers both. The booking gate is never skipped. It is satisfied by a record standing for a meeting that genuinely happened.
• A decline type was added to the task. Declining a step already means the work did not happen, and compression makes the same keystrokes also mean it happened elsewhere. Without a field to tell those apart, an automation reading the free text reason would create a record of a meeting that never took place.
• The new automation writes no attendee of any kind, and refuses to act when there is no source meeting to compress into. It can record a real meeting and cannot invent one. That was verified on a record the automation itself created, not only on its design.
• It deployed clean, switched on clean, and did nothing. A run whose condition is false still reports success, and a second fault killed every later run with a message that named no step. Both were found by reading the records rather than the run status.

A CRM product catalogue is usually typed in once and then quietly drifts from whatever document is supposed to govern it. This one is generated, and the drift it replaced had been sitting there unnoticed.

• The catalogue is built by a script that parses the canonical pricing document and writes the products, the units and the price list from it. Nothing in the CRM restates a figure, so the two cannot be edited apart by hand.
• The catalogue that already existed disagreed with that document in three ways: a rate the document explicitly supersedes, a recurring figure matching no published tier, and several products carrying no price at all. Nothing had noticed, because nothing was looking.
• A verification script now compares the live catalogue against the document and runs in the daily close out. It shares only the parser with the build, so a build that wrote the wrong value still fails the check. It was made to fail on purpose before being trusted: a seeded change produced exactly the two expected failures and a non-zero exit, and the source file was restored and confirmed identical afterwards.
• One rule was recorded too broadly, applying a minimum commitment to every tier rather than to the single engagement option that carries it. That mattered beyond the documentation, because product descriptions appear on quote lines, so the wrong version would have stated a commitment to a customer on engagements that do not have one.

A document the system generates had to be handed over for a person to upload by hand, because sending the file through the tooling cost too much. That turned out to be a fact about typefaces rather than about documents.

• The skill builds a one page executive summary from what the customer said on the discovery call, quoting them rather than summarising, and files the PDF onto their record itself.
• The earlier measurement put a single page at roughly 178,000 tokens, which is what ruled this out. Re-measuring showed the cost is driven by how many typefaces are embedded, not by length. One page using a single family came in at 232 kilobytes against 521 for one using eleven.
• The size check now runs at the moment of upload rather than sitting in the documentation as a claim. Over the limit, the file is handed over and the number reported.
• The generator can refuse. The field holding the customer’s own cost figure accepts anything, and on one record it held a number identical to that company’s revenue. Reading that field and printing it produces a confident wrong document, so an implausible value stops the run.

Before Authgnosis approaches a prospective client, it scores that company against a detailed ideal customer profile, so outreach only goes where the services and Marissa Wright’s experience are a reasonable fit. This build doubles as a proof of concept for the enterprise sales and customer lifecycle automation work, where the aim is that a salesperson stays in the browser the CRM already lives in.

• The client-fit score combines what a company does, read from its website, with its size, read from the CRM. Reading the CRM needed a database connection that exists only on one desktop, so answering a fit question meant leaving the browser where the CRM lives, getting the answer elsewhere, and coming back.
• A read only endpoint now serves that lookup over an authenticated connector, so the check runs in the browser session alongside the CRM. It offers one operation and no general query, so a surface that can score a company cannot do anything else with the CRM.
• Fixing CRM access alone would not have been enough. The scoring also called a local script to gather website evidence, so it would have failed on its first action before reaching the CRM at all. It now falls back to fetching the pages itself and collecting the same named signals. Confirmed by scoring a company end to end from a browser session.
• Running both evidence paths against the same company exposed a defect in the preferred one. The script reported navigation labels where the pricing tiers should have been, and missed the sales button beneath each tier. Those are the signals the fit rubric arbitrates on.

Every contact and account carries a last engagement date and type, stamped by three small automations whenever an email, a call or a meeting completes. A reframe email sent one to one from a lead had stamped nothing, and the reason was structural rather than a bug.

• The automations only recognised an activity filed against a contact or an account. An activity filed against a lead, which is where early conversations live, fell through both branches and the record stayed silent.
• Each of the three now looks up the lead’s parent contact and account and stamps both. All three were proven on throwaway test records before the change went live, and the one real gap was filled by hand.
• The same session added a yes or no flag on every contact showing whether they are the primary contact for their account, kept true by two automations and set correctly across 255 existing contacts.
• The twelve month nurturing email series was rebuilt on the one email structure now used everywhere, with months two to twelve created as shells ready for their text.

Before any change to how the sales process behaves, a rehearsal runs the whole twenty step chain against a test record and reports what broke. It had been stopping at the second step for three days, and nothing said so, because a rehearsal nobody runs looks exactly like one that passes.

• The rehearsal did not know about a question added to the process the day before, so it never cleared that answer between runs. The test record carried a stale answer from an earlier run, which made the first step pass for the wrong reason.
• It also never attached the document that the process has required since the end of August before it will close a review step. That is what stopped the run at step two, so steps three to twenty had not actually run in three days.
• Both were repaired. The full chain now passes twenty one of twenty one steps, the count of records created comes out exact, and the test record is left clean.
• It was found only because a separate change needed proving. Nothing reports a rehearsal that is not being run.

Every step in the sales process raises a piece of work, and declining a task with a reason has always marked its step excused so the process moves on. An email step had no such route. A rep who judged the email unnecessary had to send something anyway or tick the record by hand.

• Two fields were added to the email record, an acceptance status that defaults to yes and a reason for decline, mirroring what tasks already carry.
• A new automation watches for an email cancelled with the status set to no and a reason written, and ticks the step exactly as a sent email would. A cancel on its own, or a decline with no reason, excuses nothing, so duplicates and mistakes stay harmless.
• It was proven on a throwaway test record with three cases before anything real touched it. The reasoned decline ticked the step and both negatives held.
• The rehearsal that gates every process change gained a check it was missing, the path where a partner coordination call is correctly not raised. Running it also exposed two checks that had gone stale when a rule changed the day before, and both were corrected.

A signature record was patched, verified clean, and kept arriving in inboxes with its original content. Four attempts across two working sessions had corrected the wrong thing.

• The signature is stored in three columns. Insert Signature reads two of them, and every patch so far had written only the third, so the record read correct in every query and sent the old content.
• Writing all three columns fixed it. The proof was a received message, not a read of the stored record: a stored copy looks self consistent either way, which is how the defect survived two earlier attempts.
• The logos moved from inline base64 to hosted files. That removes about 55KB from every send and lets the two most clicked links carry campaign attribution.
• A separate change to the signature card means an existing record now repositions its own card the next time someone opens and saves it, with no migration and no manual step.

• Skills that read the CRM only ran on the machine holding the CRM connection, because that connection is a local process rather than an account level integration. A scoring skill therefore could not run in a browser session or on a schedule, whatever else was available to it.
• The obvious control, allowing only named skills to call the endpoint, is not available. The protocol carries no skill identity: a server sees tool calls and not what invoked them. So the restriction had to come from the operations on offer. The endpoint exposes a single account lookup rather than a general query interface, because a read-only credential answering arbitrary queries is still answering arbitrary queries.
• Read-only was verified by attempting a write and having it refused, rather than by reading the permission definition back. Those are different claims: one describes what the credential can do, the other describes what someone intended.
• Revenue figures are returned with their currency attached, because the scoring bands are set in Canadian dollars and a figure in another currency places a company a full band too high. The currency travels with the number so it cannot be dropped in transit.

• Microsoft is withdrawing the AI Builder credits that come seeded with Power Platform and Dynamics licences on 1 November 2026, and new customers can no longer buy the capacity add-on. The AI layer planned for the sales process was costed against an entitlement that expires, so it needed re-pricing whatever it ended up being built on.
• The comparison was made on the work the process actually runs, which is drafting and content checking rather than prediction. At current volume the cost gap between the options is small enough that it should not decide anything, so the decision had to rest somewhere else.
• It rested on where the instructions live. A prompt held inside the platform never appears in a diff or a pull request, so nothing detects when it drifts. A prompt held as a file in the repository reviews like the rest of the code.
• Predictive deal scoring stays out of scope. It needs a fitted model and enough closed history to fit one on, which is a data question rather than a model question.

A step in the sales process was deciding whether a partner was in a deal by looking at who would deliver the work. Those are different questions, and the answer to one is not the answer to the other.

• The process now asks the question directly, early in the Awareness stage, and accepts three answers: yes, no, and not known yet. The third is not treated as an answer, so the task stays open rather than the process deciding by default.
• Where the work is partner delivered, the answer is filled in automatically, because that case already settles it.
• A later step that depends on the answer no longer goes quiet when nobody has given one. It raises a task saying what it is waiting for, and why nothing further will appear until then.
• The step numbers were respaced first, from consecutive to gapped, so inserting a step no longer renumbers every step after it. The new step used the first gap the same day.

A CRM email signature was rendering its logos centred instead of left aligned, and the usual way of checking said it was fine. What makes it worth writing up is not the fix, it is that the check itself was blind. The same message looks correct in Outlook whichever account it arrives through, so opening it in a second mailbox would have confirmed the wrong answer twice.

• The defect was invisible in the one place it was being checked. The editor that composes these emails wraps every inserted image in a block that carries two separate instructions to centre it. Gmail, Apple Mail and mobile webmail all obey those instructions. Outlook renders with a different engine that ignores both, so it quietly left aligns and shows a clean result. An earlier review had raised the centring and been told it could be ignored, on the grounds that it was not showing up in Outlook. That reasoning used the one client blind to the fault as the judge of whether a fault existed.
• Patching the stored record did not work, three times, and the record was not the problem. The signature is held in three separate fields. Each was corrected and verified, and two subsequent sends still arrived centred with no trace of the correction. In the same message, a content card inserted by a small script came through correctly aligned. That contrast was the whole diagnosis: inserting a signature makes the editor redraw the images and reapply its own default, discarding whatever was stored, while the script writes the entire body as one value and the editor accepts it unchanged.
• So the fix had to move to the only write that survives. The card script already rebuilds the whole body each time it runs, so it now normalises alignment in the same pass. The trade is stated rather than hidden: it straightens every image in the body, not only the two logos, and it only runs when a card is inserted. Both are acceptable here and both are recorded, because an undocumented side effect becomes a defect the moment somebody wants a centred image.
• One behaviour explained three separate symptoms, and a finding that was true elsewhere was false here. Paragraph spacing was collapsing, the logos were centred, and a gap above the card kept vanishing. All three came from the same normalising pass: it zeroes margins on paragraphs, collapses empty lines, and rewraps bare images. Earlier work had established that a plain paragraph keeps the mail client’s own spacing, which is correct on the path where the text is written directly into the record and wrong on the path that goes through the editor. Same markup, opposite result, because different software touches it.

Four sales process automations in Dynamics 365 were repaired in one day. What made the day worth writing up is not the repairs, it is that three of them reported success while the branch they added had never executed once. Each fault was found by asking which test actually runs the new code, rather than whether the test suite passes.

• A branch that could not be reached by an empty value was being reached by one. Each automation reads a step field from the record that triggered it and matches it against a list of cases. When that field is empty the platform fails the whole evaluation before it attempts any match, and the default case does not catch it, because a default handles a value that matched nothing rather than the absence of a value. Two internal design documents had reasoned the opposite from the same definition. Both were wrong, and both are now corrected.
• One of the four reported 200 runs and zero failures while carrying the identical defect. Its trigger only fires when a record moves into a closed state, and the records it watches are already closed when they arrive, so the faulty path was never entered. A clean failure count was evidence that the code had not run. It was not evidence that it worked, and reading it as such is how the same fault survived a fix applied to its sibling that morning.
• One automation had been retired because its only working guard was accidental. It closed a process step whenever a note appeared whose subject contained a particular phrase and which carried an attachment. Nothing ever read the attachment. On the day it was examined, six unrelated notes on a single record matched the phrase, and the only reason the step did not close roughly 97 minutes early is that none of them happened to have a file attached. The trigger is now an explicit marker written by the process that completes the work.
• The pattern behind all three was the same, and it is worth naming. Each change also updated the test harness in a way that stopped the harness reaching the new code. The sharpest case: a step that reopens a task when its evidence is missing had been failing on every attempt since it was written, because it set a status value this system does not define, and the same change that added it taught the harness to supply the evidence, so the harness always took the other path. Ask which test executes that specific branch, and be most suspicious when the test was edited alongside the code.

• The CRM assigns a response code the moment a campaign reply arrives, and the routing automation only fired when that code was later changed by hand. A reply the platform coded correctly on arrival therefore never triggered anything and no lead was created. Nothing recorded that it had happened.
• Create time routing now acts on a single code. A reply coded Interested creates a lead and a task asking for it to be reviewed. Every other code waits for a person to classify it, so an automated misread can never suppress a contact.
• Reclassifying a response raises a confirmation task instead of acting immediately. Completing the task applies the change and cancelling it leaves everything as it stands. A response coded back to Interested reactivates the original lead rather than creating a second one.
• Two saved views were built before go live rather than after, so the rate of leads created in error is countable from the first week instead of estimated later.

Judging whether a marketing list had been over mailed used to mean opening each member one at a time. It now reads off the list itself.

• An Outlook template became a native CRM template. The recipient first name now resolves as a merge field, and the signature images were rehosted so they render for people reading outside Outlook.
• The Members view carries engagement history. Last contact engagement, engagement type, and the date a member was last included in a campaign now read straight off the marketing list.
• Account fit sits beside contact recency. ICP fit score joins in from the account record, using an outer join on purpose so that members with no parent account still appear instead of quietly dropping out of the list.
• Sorting works where the data lives. Columns stored on the record sort and filter normally. The joined fit score displays but cannot sort, which is a platform limit rather than a configuration choice.

The website contact form creates a Lead in the CRM, and until now it decided whether a submission was a duplicate by comparing the email address as a plain string. That was wrong in two opposite directions at the same time, and both were live. A returning prospect asking about something new was filed as a repeat and never became a Lead, so genuinely new interest went into the record as a note instead of the pipeline. Meanwhile one person writing in from x@, x+something@ and a capitalised spelling of the same address became three separate Leads, because nothing tidied the address before comparing it. The fix addresses both, and it is now live.

• Addresses are normalised before they are compared. The address is trimmed and lowercased, and a plus tag is stripped, so a person who uses tagged addresses is recognised as one person. Google accounts additionally ignore dots, so dots are removed for those and only those. That restriction matters more than it looks: for most providers a.b@ and ab@ are two different mailboxes, so applying the rule everywhere would have fixed duplicate records by silently merging two real people, which is a worse failure than the one being fixed.
• A repeat only counts as a repeat if nothing new is being asked. The form asks what the enquiry is about, and those answers are now part of the decision. Ask about something never asked before and it creates a Lead, even from a familiar address. Ask about the same things again and it stays a note on the existing Lead, exactly as before. Asking nothing in particular is treated as its own kind of request rather than as a match for everything.
• The comparison is bounded to six months. Someone returning after half a year is a new opportunity, not a duplicate of an old one.
• Verified by submitting the real form, not by reading the change. Eleven submissions were put through the live form covering both outcomes, each confirmed by which record it actually produced. One of them exists purely as a control: it proves the six month filter really is excluding old records rather than quietly matching nothing, which would have looked identical from the outside and made every other test pass for the wrong reason. All test records were then deleted and their absence confirmed by re-reading the database.

The weekly SEO, AEO/GEO, and site-health metrics Authgnosis already tracks now flow automatically into Dynamics 365 as a live, on-brand dashboard – so the full trend of how the site is performing in search and in AI answers is one click away in the CRM, with no spreadsheets and no manual entry.

• Created a purpose-built table in the CRM to hold a weekly snapshot of 16 key metrics – search impressions and clicks, average position, referring domains and backlinks, on-page quality score, Core Web Vitals, brand mentions in AI answers, and more – so each run adds one row and a real time series builds itself.
• Wired the weekly SEO monitor to write its results straight into that table automatically, authenticating as a dedicated service account – the dashboard stays current on its own, with zero manual data entry.
• Built a native model-driven dashboard, ‘SEO / AEO / GEO Health’, with eight on-brand charts (impressions, average position, referring domains, AI mentions, AI-answer citations, homepage load speed, on-page score, and data budget) and surfaced it right inside the day-to-day sales app.
• Backfilled historical rows so the charts open with a real baseline and trend from day one, instead of an empty grid waiting to fill up.

Two improvements to the Authgnosis CRM automation: new contacts now pick up their company’s website automatically, and outreach emails are now timestamped by when they were actually sent.

• When a new contact is added under a company that already has a website on file, the contact now inherits that website automatically. Every existing contact was backfilled the same way in one pass, so the field is populated across the board rather than left blank.
• The inheritance only ever fills a blank – it never overwrites a website that was entered by hand.
• The ‘last contact’ engagement timestamp for emails now uses the true send time, rather than a less reliable field that could record midnight. The record now reflects when outreach actually happened, down to the minute.

Every Account in the Authgnosis CRM now carries a live last-touch indicator: when anyone at that company was last emailed, called, or met, and how – updated automatically the moment it happens.

• Added two fields to the Account table: Last Contact Engagement (date/time) and Last Contact Engagement Type (Email, Phone Call, or Meeting), shown read-only on the main Account form.
• Shipped the Authgnosis publisher and solution first, so this and all future customizations carry a proper ag prefix instead of the platform default – portable, reviewable, and rollback-friendly.
• Engineering detail: Dynamics rollup columns cannot see activity logged against a Contact from its parent Account (a one-hop limit Microsoft documents), so three small Power Automate flows stamp the Account whenever a qualifying email, call, or meeting completes.
• Built, activated, and verified end-to-end with a live test run – a completed phone call stamped its account within about a minute, confirming the whole chain works in production.

• Mapped every field from a sales-intelligence platform’s export into the matching CRM account and contact records
• Caught the transforms that trip up imports – values stored in thousands, and picklists that must match the CRM’s own options
• Corrected a mis-typed date field so a “year founded” value imports as a whole number instead of a full date
• Locked the whole mapping into a single versioned reference so it stays authoritative across tools

Claude can now manage the Authgnosis CRM directly through the Dataverse API, with every future change tracked, auditable, and reversible through a new change-control repo wired into the daily close-out workflow.

• Stood up programmatic access to the Authgnosis CRM (Dynamics 365 Sales Professional). Claude now works the CRM through the Microsoft Dataverse API using a service principal instead of via Claude’s CoWork screen control.
• Debugged a chain of integration obstacles along the way: a missing Microsoft first-party service principal, a Claude/Microsoft Entra OAuth incompatibility, and a broken official MCP proxy. Resolved with the community mcp-dataverse server (79 tools).
• Established a change-control repo in GitHub to mirror change-control for other Authgnosis projects: backlog, per-change audit trail, before/after snapshots, and documented rollback paths.
• Wired the repo into the daily close-out workflow, including this Activity Feed publisher hook.