Intelligent systems, built to do real work.

Problem

Problem and use case

Engineering knowledge and work tracking live in Jira and Confluence, out of reach of AI assistants.

Teams look up issues, documentation and ticket history across Jira, Confluence and Zendesk. This project lets an AI assistant do that through well-defined tools instead of copy-and-paste, so questions like “what’s open in this project?” can be answered from the source systems.

Role

My role and contribution

Designed and built the MCP servers, the LangGraph agent and the Streamlit interface as a personal project.

Implementation

Implementation details

• Four FastMCP servers expose Jira Cloud, Confluence Cloud, Zendesk and US weather data as typed tools that call each service’s REST API with httpx.
• Jira tools: create, read, search with JQL, update, comment on and transition issues; list projects, issue types and project issues.
• Confluence tools: list spaces, read, search, create and update pages, comment on pages and list a space’s pages.
• Each server runs over stdio for desktop AI clients such as Claude Desktop, or over SSE on its own local port.
• A LangGraph ReAct agent (Azure OpenAI, temperature 0) discovers every server’s tools through LangChain’s MultiServerMCPClient.
• A Streamlit chat app connects to the agent and offers quick-start prompts.

Decisions

Engineering decisions and trade-offs

Tools in servers, reasoning in the agent

Integrations live in MCP servers, so the same tools serve both a desktop AI client and the custom agent without duplication.

Two transports from one codebase

stdio suits local desktop clients; SSE lets a separate agent process connect to several servers at once.

Deterministic model settings

The agent runs at temperature 0 to keep tool selection predictable.

Reliability

Error handling, security and reliability

• Credentials are read from environment variables, not hard-coded, and sent as API tokens over HTTPS.
• Access is bounded by what the API token’s account can see; there is no extra permission layer.
• Write tools (create, update, transition) are exposed alongside read tools, with no approval step.

Demo

Demonstration

• (opens full size in a new tab)

• (opens full size in a new tab)

• (opens full size in a new tab)

• (opens full size in a new tab)

Results

Tests, results and learnings

• Demonstrated end to end: from one request, the assistant pulled a sprint's issues from Jira, produced a sprint analysis report, created a Zendesk ticket and attached the report.
• No automated tests yet; the tests folder is a placeholder.
• Learning: narrowly scoped, clearly described tools make an agent’s tool choices far more reliable.
• Learning: the MCP server runs outside the AI client, so it can't read files the client creates. Sending content directly (upload_text_as_attachment) worked where file paths did not.

Next steps

Limitations and future improvements

Links

Code and demos

• View source on GitHub(opens in a new tab)

Problem

Problem and use case

An internal automation team spends too long finding technical knowledge and troubleshooting steps across documentation.

Engineers on an automation team need answers about workflows, configuration and troubleshooting. Instead of searching documentation by hand, they ask the agent in a chat window; it retrieves the relevant passages from the knowledge base and answers from them, so knowledge is easier to discover and less dependent on individuals.

Role

My role and contribution

Designed and built the retrieval agent workflow in n8n: the agent prompt, model and fallback setup, memory and the Qdrant retrieval tool.

Implementation

Implementation details

• Ingestion: a separate n8n workflow is triggered when a file is created in Google Drive, filters it, downloads it, routes PDFs through text extraction and two JavaScript clean-up steps, then embeds the text with Ollama and inserts it into the Qdrant collection through a document loader.
• An n8n chat trigger receives each question and passes it to an AI Agent node.
• The agent's main model is Llama 3.3 70B on Groq, with Azure OpenAI gpt-5-nano configured as a fallback model.
• Retrieval is exposed to the agent as a tool: a Qdrant vector store in retrieve-as-tool mode over the abi-rag collection.
• Questions are embedded with the nomic-embed-text model through Ollama before the similarity search.
• The prompt requires the agent to search the documents, answer only from retrieved content, and otherwise reply “I couldn’t find relevant information in the documents.”
• A windowed buffer memory keeps recent turns per chat session, so follow-up questions keep their context.

Decisions

Engineering decisions and trade-offs

Grounded answers over general chat

The agent is told not to answer from its own knowledge, which keeps answers tied to the team’s documentation.

Retrieval as a tool

The vector search is a tool the agent calls, rather than a fixed retrieval step, so the agent decides what to search for.

Model fallback

A second model takes over if the primary one fails, so a provider outage doesn’t take the assistant down.

Separate embedding model

A dedicated embedding model (nomic-embed-text via Ollama) is used for search, independent of the chat model.

Reliability

Error handling, security and reliability

• Fallback model configured for the agent.
• A fixed answer is returned when no relevant documents are retrieved, rather than a guess.
• Grounding is enforced through the prompt; answers are not automatically checked against the retrieved text.
• The public version will use sanitized or synthetic documents; no internal documentation, company details or credentials are published.

Demo

Demonstration

• (opens full size in a new tab)

• (opens full size in a new tab)

• (opens full size in a new tab)

Results

Tests, results and learnings

To be documented.

Next steps

Limitations and future improvements

Links

Code and demos

All three workflows (document ingestion, the retrieval agent and the multi-turn variant) are built and running in my n8n instance. The instance is private, so no public link is shared.

Problem

Problem and use case

Understanding automation health meant writing SQL against the execution database and assembling reports by hand, so trends, failures and recurring issues were slow to surface and hard to reach for anyone who doesn't write queries.

Automation execution data lives in PostgreSQL, and answering a question like “which automations failed most this week, and is it the same issue each time?” used to mean writing SQL and building a report by hand. I built an AI assistant that does that work. People ask in plain language; the assistant retrieves the relevant execution records and metrics, analyses them for failures, recurring issues and performance patterns, and explains what it found, so operational reviews and troubleshooting start from insight rather than from a query.

Role

My role and contribution

Company project, designed and built end to end.

Implementation

Implementation details

• Question: a user asks about automation performance or operational trends in natural language.
• Orchestration: LangChain coordinates the workflow, from interpreting the question through data retrieval to LLM analysis.
• Retrieval: the relevant automation execution records and performance metrics are retrieved from PostgreSQL with SQL.
• Analysis: an LLM analyses the retrieved results to identify failures, recurring issues and performance patterns, based only on the data available.
• Insights: the assistant returns contextual insights that support operational reviews, troubleshooting and continuous improvement.

Decisions

Engineering decisions and trade-offs

Ground answers in the database

Insights are drawn from the execution records actually retrieved from PostgreSQL, not from the model's general knowledge.

LangChain for orchestration

LangChain ties together the steps from question to retrieval to analysis, keeping each one separate and replaceable.

Natural language as the interface

Anyone who needs performance data can ask for it directly, without writing SQL or waiting for a report.

Insight, not just numbers

The LLM turns raw execution results into explanations of failures, recurring issues and trends that a team can act on.

Reliability

Error handling, security and reliability

• Analysis is based on the execution data retrieved for each question.
• Company systems, schemas and execution data are confidential and not shown here.

Demo

Demonstration

Screenshots and a demo will be added.

Results

Tests, results and learnings

• Reduces manual effort in querying databases and preparing performance reports.
• Makes automation performance insights accessible through natural-language interaction.
• Improves visibility into execution trends, failures and operational health.
• Supports faster troubleshooting and data-driven decision-making.
• Helps identify opportunities to improve automation reliability and efficiency.

Next steps

Limitations and future improvements

Links

Code and demos

Built as a company project, so the code, schema and execution data are confidential and no public link is shared.

Problem

Problem and use case

Finding a good place to eat means juggling ratings, reviews, distance and pricing across several searches.

On a long weekend I wanted to find a good restaurant for my family, and spent far too long comparing ratings, reviews, distance and prices. So I built an agent for it. I can ask, for example, “Find me a good South Indian restaurant near me, rated above 4.2, under ₹800 per person”, and the agent understands the request, searches real restaurants, filters and ranks them, and recommends up to three with a reason for each.

Role

My role and contribution

Personal project, designed and built end to end.

Implementation

Implementation details

• The agent is a LangGraph StateGraph: each step is a node that reads and updates a shared state.
• Extract: the LLM turns the request into structured fields (location, cuisine, budget, minimum rating, diet) and notes any standing preferences to remember. The previous search is passed in, so a follow-up changes the last search instead of starting over.
• Apply preferences: new standing preferences are saved, and empty fields are filled from the user's saved ones. The request always wins. If the user says “near me” and no location is known, the agent asks for one.
• Search: Google Places Text Search, restricted to the searched area's map box (or a box around the default location for “near me”), so a rare cuisine returns nothing rather than restaurants in another city.
• Filter: plain Python drops closed places, ratings below the minimum and places over the per-person budget. Places with unknown prices are kept.
• Rank: plain Python scoring adjusts each rating for its review count, so a 4.9 from 12 reviews doesn't beat a 4.6 from 3,000, with small penalties for distance and unknown price. The top 8 go forward.
• Pick: the LLM drops places that don't fit (for example, the wrong cuisine), chooses up to three and gives a one-sentence reason from the listed facts. If that call fails, the score order is used instead.
• Respond: writes the answer, or the reason there's nothing to show, as Markdown with Google Maps links.
• Memory: a checkpointer keeps each conversation's state for follow-ups, and a store keeps each user's preferences across conversations. Both use PostgreSQL when a database is configured, otherwise in-memory.
• The LLM provider is chosen by configuration (Groq, OpenRouter or Anthropic). It runs as a terminal chat or on a LangGraph server with Agent Chat UI.

Decisions

Engineering decisions and trade-offs

LLM plus deterministic code

The LLM handles language and the final judgement of fit; opening hours, ratings, distance and budget are plain Python, so they behave the same on every run and are easy to test.

Small, explicit nodes

Each step is its own node, so it can be tested and reasoned about on its own.

Structured output

The LLM's answers are constrained to schemas, so the application uses them without parsing free text.

Restrict search to the area

Results are kept inside the searched area's map box, so an unusual request returns “nothing found” instead of confident results from another city.

Conditional edges for real outcomes

An unknown location, no results, no matches and no relevant matches each take their own path, so poor matches are never presented as good ones.

Checkpoints and memory are different

The checkpointer continues a conversation; the store remembers a user's preferences across conversations.

Reliability

Error handling, security and reliability

• Filtering, scoring and budget rules are deterministic Python, so they behave the same on every run.
• If the LLM ranking call fails, the agent falls back to the score order instead of failing the request.
• Internal steps are kept out of the chat stream, so the user only sees the final answer.
• 88 automated tests run with a fake LLM and saved Google Places responses, so they need no API keys; a PostgreSQL persistence test runs when a database is configured.
• No live availability or booking is claimed; reservations are a planned next step.

Demo

Demonstration

Screenshots and a demo will be added.

Results

Tests, results and learnings

• Unit tests passed, but testing with real data exposed problems they missed: location issues, loose budget rules and unexpected LLM decisions.
• Real-world data is messy: a search for Korean BBQ in a small town confidently returned restaurants in Tulsa and Honolulu. Restricting the search to the area's map box fixed this.
• Learning: checkpoints and memory solve different problems. Checkpoints continue a workflow; memory remembers a user's preferences.

Next steps

Limitations and future improvements

Links

Code and demos

Runs locally on a LangGraph server with Agent Chat UI; there is no hosted demo yet.

• View source on GitHub(opens in a new tab)

Problem

Problem and use case

Posting regularly about AI on LinkedIn meant scanning news every day, picking a topic that hadn't been covered, researching it and writing in my own voice, which took more time than I had.

I wanted to post about AI on LinkedIn regularly without spending an hour a day on it. Every morning this workflow does the groundwork: it reads AI and developer news, chooses a topic I haven't covered, researches the sources and drafts a post that sounds like me. I get an email with a review form, edit the draft if I want, and approve or reject it. Only an explicit approval publishes, and the exact text I submit is what goes out.

Role

My role and contribution

Personal project, designed and built end to end in n8n.

Implementation

Implementation details

• Schedule: a daily 8 AM trigger reads a config of approval address, a 72-hour lookback window and 30 days of topic history.
• Discovery: 14 RSS feeds (Hugging Face, OpenAI, Simon Willison, Latent Space, GitHub Changelog, InfoQ, The New Stack, Cloudflare, Hacker News, GitHub Trending, MarkTechPost and a Google News query for agents and MCP) are read with no API keys.
• Candidates: JavaScript scores items for developer and agent relevance, filters out consumer and business news, and drops anything outside the lookback window.
• Topic: an LLM picks topics with structured output; code then rejects any whose keyword hash or token similarity (Jaccard ≥ 0.4) matches a post from the last 30 days.
• Research: one to four source articles are fetched and an LLM writes a structured research brief.
• Writing: the writer prompt combines the brief with my newest style profile and up to four of my real posts, and an LLM drafts the post.
• Lint: code converts Markdown to LinkedIn-safe Unicode bold and bullets, and checks the draft against a list of around 50 banned clichés; a failing draft is rewritten once.
• Approval: the draft is saved as pending_approval and sent by Gmail with a review form. I can edit the text, then approve or reject; no response in 20 hours counts as not approved.
• Publish guard: before LinkedIn is called, the saved draft is re-read, checked for status, length and duplicate topic or text, and locked from pending_approval to publishing.
• Publish: the exact approved text goes to LinkedIn, the post URL is captured, and a Telegram community is notified.
• Style learning: a separate form takes my real posts, an LLM analyses them into a reusable style profile, and approved edits whose word overlap with the draft is below 90% are saved as new samples.
• Models: free OpenRouter models (Nemotron 3 Ultra for writing, Nemotron 3 Super and Gemma 4 31B for analysis) with Gemini Flash as the fallback.

Decisions

Engineering decisions and trade-offs

Human in the loop

Nothing is published without an explicit approval, and the exact text I submit is what gets posted, so the automation never speaks for me unreviewed.

Deterministic checks around the LLM

Relevance scoring, duplicate detection, formatting, cliché linting and the publish guard are plain JavaScript, so they behave the same on every run.

Learn from real writing

The writer uses my own posts and a style profile built from them, and my edits feed back in as new samples, so the drafts get closer to my voice over time.

Guard the publish step

Re-reading the draft, blocking duplicates and locking the row before calling LinkedIn prevents double posts even if the approval is submitted twice.

Free models with a fallback

Free OpenRouter models keep the daily run at no model cost, and Gemini Flash takes over when they fail.

Bounded rewriting

A failing draft gets exactly one rewrite, which keeps the run predictable instead of looping on the LLM.

Reliability

Error handling, security and reliability

• Publishing requires an explicit approval; a 20-hour timeout counts as not approved.
• The publish guard blocks duplicate topics, identical text and drafts that are no longer pending.
• Approved text must be between 50 and 3,000 characters.
• Every draft, decision and publish result is recorded in n8n data tables.

Demo

Demonstration

Screenshots and a demo will be added.

Results

Tests, results and learnings

• Runs every day: 15 daily runs recorded between 8 and 22 October 2026, 11 completed, 3 ended in an error and 1 was awaiting approval.
• Turns daily topic research and drafting into a single review step.

Next steps

Limitations and future improvements

Links

Code and demos

Runs in my private n8n instance, so there is no public link.

Problem

Problem and use case

Renewing and reissuing TLS certificates for CDN enrollments was a multi-step manual process across Akamai and Sectigo, with each hand-off a chance for delay, a mismatched SAN list or an unvalidated production change.

TLS certificates on Akamai enrollments have to be renewed before they expire, and sometimes reissued with new SANs. Done by hand, that means downloading the CSR from Akamai, submitting it to Sectigo, waiting for issuance, uploading the certificate, checking staging and promoting to production, with plenty of room for delay or error. I automated the whole lifecycle in two capabilities: renewal, triggered by an engineer through an HTTP endpoint, and reissue, which adds new SANs to an existing enrollment and is requested through a Zendesk macro. Every run is tracked in a Zendesk ticket.

Role

My role and contribution

Company project, built as part of my enterprise automation work.

Implementation

Implementation details

• Trigger: renewal starts from an HTTP endpoint call; reissue starts from a Zendesk macro that captures the request type, SANs, enrollment ID and target environment.
• Tracking: a Zendesk ticket is created automatically and each step is recorded on it. Ticket communication uses short-lived tokens held in Redis.
• Secrets: API credentials are read from Azure Key Vault rather than stored with the code.
• Reissue only: a Python script updates the enrollment's SAN list through the Akamai API before a new CSR is generated.
• CSR: the CSR is downloaded from the Akamai enrollment using EdgeGrid-authenticated API calls (edgegrid-python, requests).
• Issuance: the CSR is submitted to the Sectigo REST API and the issued certificate is retrieved.
• Staging: the certificate is pushed to the Akamai staging network and validated.
• Validation: SANs are compared between staging and production; the rule is that the production SAN count must exceed staging's. For reissue, this cross-environment comparison is mandatory.
• Production: deployment to production is optional per run, so a request can stop at staging or go through staging and production.

Decisions

Engineering decisions and trade-offs

Staging before production

Every certificate goes to Akamai staging and is validated first; production is a separate, optional step, so an unvalidated certificate never reaches live traffic.

Validate across environments

Comparing SANs between staging and production catches a certificate that would drop or mismatch hostnames before it is promoted.

Ticket as the audit trail

Auto-creating a Zendesk ticket and logging each step gives every renewal and reissue a complete, reviewable record.

Structured requests

The Zendesk macro captures request type, SANs, enrollment ID and environment as fields, so reissue requests arrive complete and machine-readable.

Short-lived tokens

Redis holds short-lived tokens for ticket communication, so credentials used in the flow expire instead of persisting.

Centralised secrets

Akamai, Sectigo and Zendesk credentials live in Azure Key Vault, not in code or configuration files.

Reliability

Error handling, security and reliability

• Staging deployment and validation always run before any production change.
• The staging vs production SAN comparison is mandatory for reissue.
• Every step is recorded on the run's Zendesk ticket.
• Credentials come from Azure Key Vault; ticket tokens are short-lived.
• Code, enrollments and certificate details are confidential and not shown here.

Demo

Demonstration

Screenshots and a demo will be added.

Results

Tests, results and learnings

• Reported outcome: End-to-end renewal and reissue with no manual hand-offs
• Reported outcome: Mandatory staging vs production validation
• Reported outcome: Reduced renewal time from days to minutes

Next steps

Limitations and future improvements

Links

Code and demos

Built as a company project, so the code, enrollments and certificate details are confidential and no public link is shared.

Problem

Problem and use case

Office 365 distribution lists and shared mailboxes were created, changed and deleted by hand from tickets, with approvals chased manually by email and rejected requests left for someone to close.

Teams request new distribution lists and shared mailboxes, membership and ownership changes, renames and deletions through Zendesk. Each request needs an owner's approval before anything changes in Office 365. Done by hand, that meant reading the ticket, emailing for approval, chasing it, making the change in Exchange and closing the ticket. I automated the whole lifecycle: tickets are picked up automatically, approval is requested and chased by email, rejected requests are closed, and approved changes are executed through Exchange Online PowerShell.

Role

My role and contribution

Company project, built as part of my enterprise automation work.

Implementation

Implementation details

• Intake: the automation polls the Zendesk API every 150 seconds for new distribution list and shared mailbox requests.
• Operations: each request is mapped to one of the supported operations: create, update (add or remove users, change owner, rename) or delete.
• Approval: an approval email is sent, and an email listener polls every 30 minutes for the response.
• Chasing: if no response arrives, the approval is chased up to three times.
• Rejection: if the request is rejected, the Zendesk ticket is resolved automatically.
• Execution: approved requests run as Exchange Online PowerShell through Resolve.
• Identity: the automation integrates with Active Directory for the users and owners named in a request.
• Secrets: credentials are read from Azure Key Vault rather than stored with the automation.

Decisions

Engineering decisions and trade-offs

Approval before change

No distribution list or shared mailbox is created, changed or deleted until the approval comes back, so the automation enforces the same control as the manual process.

Automatic chasers

Chasing approval up to three times removes the most time-consuming manual step without waiting on someone to follow up.

Close rejections automatically

Resolving rejected tickets straight away keeps the queue clean and gives requesters an immediate outcome.

Polling suited to each source

Zendesk is polled every 150 seconds so new requests start quickly, while approval replies are collected by a separate email listener every 30 minutes.

One flow for the whole lifecycle

Create, update and delete share the same intake and approval path, so every change goes through the same controls.

Centralised secrets

Credentials live in Azure Key Vault, not in scripts.

Reliability

Error handling, security and reliability

• Every change requires approval before it is executed.
• Rejected requests are closed automatically, so none are left open.
• Credentials come from Azure Key Vault.
• Code, mailboxes, lists and ticket data are confidential and not shown here.

Demo

Demonstration

Screenshots and a demo will be added.

Results

Tests, results and learnings

• Reported outcome: Create, update and delete handled end to end from the ticket
• Reported outcome: Approvals chased and rejections closed automatically
• Reported outcome: Reduced IT workload by 70%
• Reported outcome: Improved compliance

Next steps

Limitations and future improvements

Links

Code and demos

Built as a company project, so the code, mailboxes and ticket data are confidential and no public link is shared.

Problem

Problem and use case

Lottery reconciliation ran as a weekly batch on Hadoop and produced complex multi-tab reports, so sales and prize payout discrepancies surfaced up to a week late and were hard to act on.

Lottery sales and prize payouts have to reconcile store by store, and any gap needs to be found and followed up quickly. The legacy process was a weekly Hadoop batch that produced complex multi-tab workbooks, so discrepancies surfaced late and took effort to interpret. I re-platformed it as a daily pipeline: lottery data is consumed directly from a Kafka topic into PostgreSQL, reconciled in Python, and published as a two-tab Excel report, sales discrepancies and prize payout discrepancies, for Express and Large Format stores through the MyWork API.

Role

My role and contribution

Company project, built as part of my enterprise automation work.

Implementation

Implementation details

• Ingestion: a Python Kafka consumer subscribes to the source Kafka topic and connects to the brokers over SSL with mutual TLS (client certificate authentication).
• Storage: consumed records are persisted to PostgreSQL, which replaces Hadoop as the reporting data store and makes the data queryable with SQL.
• Orchestration: the Resolve scheduler triggers the reconciliation job once a day.
• Reconciliation: Python logic over the PostgreSQL data identifies sales discrepancies and prize payout discrepancies for Express and Large Format stores.
• Report generation: results are written to an Excel workbook with exactly two tabs, one per discrepancy type, replacing the multi-tab weekly workbook.
• Distribution: the workbook is published through the MyWork API, so delivery is part of the pipeline rather than a manual hand-off.

Decisions

Engineering decisions and trade-offs

Consume at the source

Reading the Kafka topic directly removes the Hadoop batch from the critical path and gives reconciliation its own pipeline, decoupled from the legacy platform.

PostgreSQL as the reporting store

A relational store suits reconciliation: discrepancies are joins and aggregations over structured records, expressed in SQL rather than Hadoop jobs.

Daily cadence

Moving from weekly to daily cuts the time between a discrepancy occurring and it being reported from up to a week to a day.

Two-tab output contract

A fixed two-tab structure (sales, prize payouts) is quicker to read than the old multi-tab workbook and gives every report the same shape.

mTLS on Kafka

Mutual TLS authenticates both the consumer and the brokers and encrypts data in transit.

Scheduler-driven runs

Running the job from the Resolve scheduler removes manual starts and keeps execution inside the existing automation platform.

Reliability

Error handling, security and reliability

• Kafka traffic is encrypted and mutually authenticated with SSL/mTLS.
• Runs are triggered by the Resolve scheduler, not started by hand.
• Code, data and reports are confidential and not shown here.

Demo

Demonstration

Screenshots and a demo will be added.

Results

Tests, results and learnings

• Reported outcome: Reporting cadence moved from weekly to daily
• Reported outcome: Hadoop dependency removed
• Reported outcome: Multi-tab reports reduced to two focused tabs
• Reported outcome: Reduced effort by 80% across 3,000+ stores

Next steps

Limitations and future improvements

Links

Code and demos

Built as a company project, so the code, data and reports are confidential and no public link is shared.

Problem

Problem and use case

When a user's access changed, their OneLogin profile had to be refreshed by hand, which delayed access updates, created security risk while old roles stayed active, and introduced human error.

When someone's access changes, their OneLogin roles need to reflect it straight away: a delay leaves people without access they need, or with access they should no longer have. Refreshing profiles by hand was slow, risky and error-prone. I automated it end to end. Access changes are sent to Splunk as events, Resolve picks up the affected users and refreshes their roles through the OneLogin API, any failures are gathered into a single Zendesk ticket for follow-up, and daily and weekly reports show what was refreshed.

Role

My role and contribution

Company project, built as part of my enterprise automation work.

Implementation

Implementation details

• Events: access changes are sent to Splunk as events.
• Detection: Resolve queries the Splunk API for the user IDs affected by those changes.
• Refresh: for each user, Resolve calls the OneLogin REST API with a PUT request to refresh the user's roles.
• Failure handling: failed refreshes are collected and raised together as a single Zendesk ticket through the Zendesk API, rather than one ticket per failure.
• Tracking: refresh activity is recorded in a tracking table.
• Reporting: daily and weekly reports are generated from the tracking table.
• Secrets: API credentials are read from Azure Key Vault.

Decisions

Engineering decisions and trade-offs

Event-driven via Splunk

Using the access-change events already flowing into Splunk as the trigger means roles are refreshed as changes happen, with no separate change feed to build.

API refresh, not manual edits

A PUT call to the OneLogin REST API refreshes the user's roles the same way every time, removing the human error of manual profile updates.

Batch the failures

Raising one Zendesk ticket for all failed refreshes gives a single, actionable work item instead of flooding the queue with one ticket per user.

Tracking table as the record

Recording refreshes in a table makes the daily and weekly reports a simple query and gives an audit trail of access changes.

Centralised secrets

API credentials live in Azure Key Vault, not in the workflow.

Reliability

Error handling, security and reliability

• Failed refreshes are never dropped: they are batched into a Zendesk ticket for follow-up.
• Every refresh is recorded in the tracking table, which feeds the daily and weekly reports.
• Credentials come from Azure Key Vault.
• Code, user data and access policies are confidential and not shown here.

Demo

Demonstration

Screenshots and a demo will be added.

Results

Tests, results and learnings

• Reported outcome: Role changes synchronised automatically instead of by hand
• Reported outcome: Failures consolidated into one ticket
• Reported outcome: Daily and weekly reporting
• Reported outcome: 100% compliance

Next steps

Limitations and future improvements

Links

Code and demos

Built as a company project, so the code, user data and access policies are confidential and no public link is shared.

Problem

Problem and use case

Routine OS patching across Linux and Windows servers relied on manual effort, which made deployment inconsistent, slowed the response to security vulnerabilities and left patch compliance and failures hard to track.

Keeping Linux and Windows servers patched is routine but essential work: every missed or failed patch is a potential security gap, and doing it by hand across many servers is slow and inconsistent. This automation runs the whole patch cycle: it works out which servers need which patches, checks they are ready, installs approved updates, reboots where needed, confirms the servers are healthy afterwards, records the outcome for every server and escalates anything that failed.

Role

My role and contribution

Company project, built as part of my enterprise automation work.

Implementation

Implementation details

• Targeting: the automation identifies the servers in scope and retrieves the patching requirements for each.
• Pre-checks: each server is validated for patching eligibility and its prerequisites before any change is made.
• Installation: approved security updates and OS patches are installed through remote execution: PowerShell scripts on Windows Server and Ansible workflows on Linux.
• Reboots: reboots are coordinated only where a patch requires one.
• Verification: system health is checked after patching to confirm each server came back correctly.
• Reporting: patching status, failures and execution results are captured for reporting and audit.
• Escalation: unsuccessful patching is escalated for investigation and remediation.

Decisions

Engineering decisions and trade-offs

Validate before patching

Eligibility and prerequisite checks run first, so servers that aren't ready are never patched mid-state.

Approved updates only

Only approved security updates and OS patches are installed, keeping automated changes within patch policy.

One workflow, two platforms

Linux and Windows follow the same targeting, validation, verification and reporting steps, with platform-specific execution: PowerShell on Windows and Ansible on Linux.

Reboot only when required

Coordinating reboots per patch requirement avoids unnecessary restarts.

Verify after every run

Post-patch health checks confirm each server is working, not just that the installer finished.

Every result recorded

Capturing status, failures and results for each server gives patch compliance visibility and an audit trail.

Reliability

Error handling, security and reliability

• Servers are validated for eligibility and prerequisites before patching.
• System health is verified after patching.
• Failures are escalated for investigation instead of being left unnoticed.
• Patching status and results are recorded for reporting and audit.
• Code, server inventory and patch data are confidential and not shown here.

Demo

Demonstration

Screenshots and a demo will be added.

Results

Tests, results and learnings

• Reported outcome: Reduced manual effort in routine server maintenance
• Reported outcome: More consistent, reliable patch deployment
• Reported outcome: Timely patching of security vulnerabilities
• Reported outcome: Clear patch compliance and failure tracking

Next steps

Limitations and future improvements

Links

Code and demos

Built as a company project, so the code, server inventory and patch data are confidential and no public link is shared.

Problem

Problem and use case

URL whitelisting and malicious-URL blocking in Zscaler were handled by hand from support tickets: reading the request, raising a change, checking each URL, updating Zscaler and confirming the result, with security checks depending on whoever picked up the ticket.

Requests to allow or block URLs in Zscaler arrive as Zendesk tickets. Handled by hand, each one meant reading the ticket, raising a change request, checking the URLs, updating the right Zscaler tenant and confirming the change took effect, and blocking needed extra security checks on top. I automated both flows. Whitelisting parses the request from the ticket, raises a Jira change request, validates the URLs, adds them to Zscaler and verifies the result in Splunk. Blacklisting extends the same flow with DNS and reputation checks before the URL is blocked, and manages the change request through its approval states.

Role

My role and contribution

Company project, built as part of my enterprise automation work.

Implementation

Implementation details

• Whitelisting trigger: the automation picks up tickets that land in a dedicated Zendesk queue.
• Blacklisting trigger: a Zendesk filter is polled every 5 minutes for new block requests.
• Parsing: ticket comments are parsed to extract the target Zscaler tenant (two tenants are supported), the URL list and the URL category.
• Change control: a Jira change request is created through the Jira API for every request.
• Validation: each URL is checked for a valid format and for accessibility before any change is made.
• Whitelisting: URLs are added to the selected tenant through the Zscaler API. After a 5-minute wait for the policy to take effect, Splunk logs are queried through the Splunk API to confirm the change.
• Blacklisting, DNS check: an UltraDNS zone lookup detects domains fronted by Akamai, so they can be handled differently from domains that resolve directly.
• Blacklisting, reputation check: each URL is scored with the VirusTotal API, where 0 means valid and −1 means risky.
• Blacklisting, enforcement: URLs are added to the Zscaler blacklist, and the Jira change request is moved through its approval state transitions.
• Runtime: the automation runs as Python in a dedicated virtual environment.

Decisions

Engineering decisions and trade-offs

Ticket as the interface

Requests keep coming in through Zendesk, so nothing changes for requesters; the automation reads the ticket instead of a person.

Change request for every action

Each whitelist or blacklist change is raised in Jira, and blacklisting follows the change's approval states, so automated changes stay inside change control.

Validate before changing policy

URL format and accessibility are checked first, so malformed or unreachable URLs never reach Zscaler.

Verify, don't assume

Waiting 5 minutes and checking Splunk logs confirms the whitelist change is actually in effect, rather than trusting the API response alone.

Layered checks for blocking

UltraDNS identifies Akamai-fronted domains and VirusTotal scores reputation before anything is blocked, which lowers the risk of blocking shared or legitimate infrastructure.

One parser, two flows

Blacklisting extends the whitelisting flow, so ticket parsing, Jira handling and Zscaler access are shared rather than duplicated.

Reliability

Error handling, security and reliability

• Every change is tracked as a Jira change request.
• URLs are validated before any Zscaler policy change.
• Whitelist changes are confirmed in Splunk logs after a 5-minute wait.
• Block requests pass DNS and VirusTotal reputation checks first.
• Code, tenants, ticket data and URL lists are confidential and not shown here.

Demo

Demonstration

Screenshots and a demo will be added.

Results

Tests, results and learnings

• Reported outcome: Whitelisting and blacklisting handled end to end from the ticket
• Reported outcome: Every change raised as a Jira change request
• Reported outcome: Whitelist changes verified in Splunk logs

Next steps

Limitations and future improvements

Links

Code and demos

Built as a company project, so the code, tenants and ticket data are confidential and no public link is shared.

Problem

Problem and use case

Generating logs for support tickets was a manual step that slowed issue resolution.

To troubleshoot a customer issue, support and engineering teams need the relevant system logs, and collecting them by hand took time and pulled engineers away from other work. This automation lets a Zendesk ticket workflow request the logs: when a ticket needs them, the workflow triggers log generation and delivers the result back automatically, so the people working the ticket get the evidence without waiting on a manual step.

Role

My role and contribution

Company project, built as part of my enterprise automation work.

Implementation

Implementation details

• Ticket: a Zendesk ticket workflow identifies tickets that need logs.
• Trigger: the ticket workflow triggers the log-generation automation, so no one has to start it by hand.
• Log generation: the automation generates the logs needed for the issue.
• Delivery: the generated logs are delivered back to the people working the ticket.

Decisions

Engineering decisions and trade-offs

Start from the ticket

Using the Zendesk ticket workflow as the trigger puts log requests where support work already happens, with no separate request process.

On demand, not scheduled

Logs are generated when a ticket needs them, so each request returns current data for that issue.

Remove the hand-off

Automating generation and delivery takes the manual wait out of the troubleshooting loop.

Reliability

Error handling, security and reliability

• Company systems, ticket data and logs are confidential and not shown here.

Demo

Demonstration

Screenshots and a demo will be added.

Results

Tests, results and learnings

• Reported outcome: Eliminated manual effort
• Reported outcome: Improved issue resolution speed

Next steps

Limitations and future improvements

Links

Code and demos

Built as a company project, so the code, integrations and ticket data are confidential and no public link is shared.

Problem

Problem and use case

High CPU and memory alerts on application servers were fixed by engineers logging into each server and running remediation scripts by hand, which was slow and inefficient.

When application servers hit high CPU or memory, the fix was usually a controlled restart, but an engineer had to log into each server and run the scripts by hand. That was time-consuming and slowed recovery. I automated the loop end to end: the monitoring alert raises a ticket, the automation checks that the server is one it is allowed to act on, performs a controlled restart, confirms from the logs that the restart worked and closes the ticket, in both PPE and PROD.

Role

My role and contribution

Company project, built as part of my enterprise automation work.

Implementation

Implementation details

• Detection: New Relic raises an alert for high CPU or memory usage on a server.
• Ticketing: the alert creates a Zendesk ticket, which starts the automation and records every run.
• Validation: Resolve checks the server against a tracking table before taking any action.
• Remediation: Resolve runs a PowerShell script over WinRM that takes the server offline, restarts it and brings it back online.
• Verification: the restart is confirmed by inspecting the server's log file.
• Closure: once the restart is verified, the Zendesk ticket is closed automatically.
• Environments: the automation runs in PPE and PROD, with separate service accounts per domain.
• Secrets: credentials are read from Azure Key Vault rather than stored in the scripts.

Decisions

Engineering decisions and trade-offs

Validate before acting

Checking each server against a tracking table means the automation only restarts servers it is meant to manage.

Controlled restart sequence

Taking the server offline before restarting and bringing it back online afterwards avoids restarting a server while it is still serving traffic.

Verify, then close

The ticket is closed only after the log file confirms the restart, so a ticket never closes on a failed remediation.

Remote execution over WinRM

PowerShell over WinRM runs the remediation remotely, removing the need for anyone to log into the server.

Separate accounts per environment

PPE and PROD use separate service accounts per domain, so a credential for one environment can't act on the other.

Ticket as the record

Every alert and remediation is tracked on a Zendesk ticket, giving a complete history of automated actions.

Reliability

Error handling, security and reliability

• Servers are validated against a tracking table before any action.
• Restarts are verified from log files before the ticket is closed.
• PPE and PROD use separate service accounts per domain; credentials come from Azure Key Vault.
• Code, servers and monitoring data are confidential and not shown here.

Demo

Demonstration

Screenshots and a demo will be added.

Results

Tests, results and learnings

• Reported outcome: Alert-to-resolution with no manual login
• Reported outcome: Restarts verified before tickets close
• Reported outcome: 90% downtime reduction
• Reported outcome: Improved system performance

Next steps

Limitations and future improvements

Links

Code and demos

Built as a company project, so the code, servers and monitoring data are confidential and no public link is shared.