And while I do use AIs and LLMs for some tasks (like podcast summaries) I’m not really a super heavy user who would understand what they really want to do with that. Meaning it didn’t really have a high priority on my tasks list, but eventually I got to it.

I hoped that Sally would show me everything in her video, but it was just first part, developer heavy and I didn’t get much out of it.

Luckily there is a documentation – which I found before – and I went through that, did all the settings and failed. Hence this article, where I will share the updates I found and maybe explain why I feel it makes sense for regular users to connect it as well.

Step 1 – Enable MCP server

When you google how to connect Claude with Salesforce you won’t find this article, but without it the authentication will fail with super weird error 405 method not allowed.

Let’s start with that and enable MCP servers in Salesforce.

If that sounds like some mambo jumbo to you I’m not surprised, but somehow behind the scene when AI asks Salesforce when it can find something or what fields are available it will give it the answers. As you can see on the screen and in the relevant article, there are plenty of different servers/end points and you enable the ones you like. I especially like the sobject-reads which will give you read only access, no worries AI will mess anything in your org.

Open the record you like and hit the Activate button and step 1 is completed.

Step 2 – External Client App

The relevant article is easy to follow, but when you set it as specified it won’t work – some scope is missing. After some googling around I found out which one – the mcp_api is crucial one!

Save, wait some time to propagate everything across servers and get the Consumer Key, you will need to add into Claude.

Step 3 – Connect Claude

Surprisingly or even maybe shockingly, Claude doesn’t have a dedicated Salesforce connector, so you need to add it manually. Good news for bigger companies – the Claude Owner/Admin can add it on the org level and users will just connect it with their own credentials.

If you want to do it manually just follow the respective article, this one works. Actually it might be better to copy the URL from the Step 1 as it is listed there clearly (and have different URL at the same time).

Settings, Connectors, Custom Connector, ugly looking URL at the of which you will add the server you like and enabled in Step 1 (no need if you copy the URL from the Step 1). In the OAuth Client ID you will paste the Consumer Key from previous step.

Success, hopefully. If not pay attention to the URL of the error page, most likely at the end you can spot what is wrong:

• app doesn’t exist means wait a bit longer/double check the Consumer Key
• invalid Scope – most likely you didn’t add all the scopes, including mcp_api
• 405 method not allowed – most likely the MCP server is not enabled.

Step 4 – Use it

I suppose you might struggle how to use it and I was the same. But then I came with simple use cases, it gave me some data which looks relevant and save some time.

For CzechDreamin I wanted to analyze who are our top speakers – meaning they spoke the most. We have every single one as a lead in our Salesforce. As a lead for every single year they submitted a topic/spoke. When Data Cloud 360 came we tried to unify them and while it kind of worked it needed some admin work for setup and wasn’t really user friendly to get this statistic. Running a report might work but it is a lot of clicks -> Claude to save me!

Can you analyze all our leads of type Speaker and tell me which email address is the most common one (top 10). Make them unique by year (count only once per year). Count only those accepted (or in working status), basically anything besides declined. Can you also parse https://czechdreamin.com/2024/ and https://czechdreamin.com/2025 and extend it with speakers from these years (map them across the years also by name in its fuzzy form)

I can imagine you will not want to get my requirements in such form, but Claude managed. A lot of thinking from its side, a few clicks to approve their approach and what they will query from Salesforce and we are done. I must admit this conversational analysis is super cool thing!

Key findings after adding 2025:

• Aaron Crear remains #1 — now confirmed across 5 years (2019, 2020, 2023, 2024, 2025)
• Melissa Shepard, Katka Vokrinkova, Mark Jones, George Avilov, Pei Mun Lim, Todd Halfpenny, Hanna Nimchuk, Lukas Vavrin, David Fernandez Rivero all gained a 2025 year, jumping to 3–4 total appearances
• Several 2025 speakers (like Andrew Fawcett, Markus Fröhler) appear website-only with no SF Lead record — worth checking if they should be created

I must admit that I start seeing the value and maybe being braver and allow the write access as well so it can create tasks for me, update opportunities etc would be worth it.

Check my salesforce and tell me how many opportunities we have for this year

You have 3 opportunities for 2026, all currently in the „Invoice sent“ stage with a 95% probability. Here’s the breakdown:

Total pipeline value: $11,200 — and since all three are at 95% probability, you’re in great shape to close them. Would you like to dig into any of these further?

can you mark all the opportunities you listed above as Closed Won?

I have the 3 opportunity IDs from earlier. Let me update all three simultaneously.All 3 opportunities have been marked as Closed Won Total closed: $11,200. Nice work!

actually create a follow-up task for me in a week time to check whether they have all information for each of those opps.

Good, got your user ID. Now creating 3 tasks — one per opportunity — due in a week (April 28).All 3 tasks created and linked to their respective opportunities, due April 28

They’re assigned to you (Martin Humpolec) and will show up in your SF task list and activity timeline on each opp.

I always have a feeling it takes for ever, but it is probably quicker than open Salesforce and go one by one or even mass update from a list view. Yes, they all have been updated to Closed Won a few seconds later and tasks have been created.

And I’m probably sold, this conversational work – which compared to my previous experience is really spot on and doesn’t need to constantly confirm that it found the right records and everything – makes it easy to work, maybe instead of typing use voice and much more.

I’m pretty sure I’m just scratching the surface of what is possible and you do on daily basis – will you share some example how you utilize it or what you feel it will allow you to do?

A few of my notes:

• “Accidental admin” is the norm
  Many people don’t plan a career in Salesforce — they grow into it by solving real business problems, which leads to a very practical mindset.
• Hands-on experience builds credibility
  Deep, practical knowledge helps you:
  • understand system behavior
  • speak confidently with tech teams
  • avoid being purely theoretical
• End-to-end thinking > platform thinking
  A strong BA looks beyond Salesforce:
  • understands integrations (e.g. SAP)
  • sees the full business process
  • avoids siloed responsibility
• Users don’t care about systems — only outcomes
  They interact with one interface, but expect everything behind it to work seamlessly.
• Delivery often fails before it starts
  The real issues are:
  • poor data
  • unclear processes
  • missing ownership
• “You can’t automate what you can’t trust”
  Bad data = unreliable automation → validate data readiness early.
• AI / buzzwords must be translated into outcomes
  “We want AI” → define:
  • measurable goals
  • specific capabilities
• Start with enablers, not shiny features
  Before advanced solutions:
  • fix data
  • clarify processes
  • ensure visibility
• Success metrics are often missing
  Teams build and move on without checking impact → no learning loop.
• Curiosity builds trust, not resistance
  Asking thoughtful questions (instead of pushing back directly) leads to better collaboration and better solutions.
• Stakeholders must co-own solutions
  Involving them early → stronger adoption, better outcomes, and internal champions.

Check the recording on your own! And presentation if you wish to just quickly skim through.

Tentokrát jsem si pozval Honzu Staňka z Domova svatého Josefa a Alenu Novotnou z Lékařů bez hranic. Dvě různé implementace, dva různé systémy, dvě různě dlouhé zkušenosti.

Zápisky:

• Salesforce v nezisku není jen CRM – je to nástroj, který umožňuje šetřit čas, peníze a posouvat fundraising dopředu.
• Neziskovky často pracují efektivněji než byznys – mají méně lidí, méně času a musí víc automatizovat.
• Výběr nové databáze je strategické rozhodnutí – musí vydržet roky, být podporovaná a rozvíjená.
• Příprava před implementací je klíčová – vědět, co chceme, proč to chceme a jak to budeme používat.
• Salesforce pomáhá s datovou kulturou – umožňuje pracovat s daty, analyzovat je a dělat fundraising data‑driven.

• 10 licencí zdarma je výhoda – ale implementace, údržba a rozvoj stojí čas i peníze, které je potřeba realisticky plánovat.
• Komunita je obrovská přidaná hodnota – neziskovky se učí jedna od druhé, sdílí postupy a inspirují se.
• Implementace může být bolestivá – první měsíce jsou často „údolí smrti“, než si lidé zvyknou a systém se usadí.
• Salesforce je jako lego – dá se postavit téměř cokoliv, ale je potřeba mít hranice, aby se organizace neutopila v možnostech.
• Automatizace šetří nejvíc času – import darů, děkování, kampaně, telefonní scénáře, mailing.

• Rychlé poděkování dárcům je zásadní – automatizace umožní reagovat okamžitě, což zvyšuje loajalitu i výnosy.
• Uživatelská přívětivost je kritická – neziskovky nemají armádu adminů, systém musí být jednoduchý pro běžné uživatele.
• Salesforce pomáhá zvednout fundraising – méně času na administrativu znamená víc času na dárce a kampaně.
• CRM není o datech, ale o vztazích – fundraising je budování vztahů a Salesforce pomáhá řídit je ve velkém.
• Hotové balíčky pro neziskovky jsou velká výhoda – integrace na banky, darujme, kampaně a další věci zjednodušují start.

When I recall all the CTA related scenarios, there probably wasn’t any, where we wouldn’t propose ESB in the picture. But worth to know that these solutions don’t have any budget constrains which makes real life decision a bit different.

A great article has been published on SalesforceBen related to this and this exact article was the reason for my blog post.

All the points in the article are valid, but the real life might be different, like on our last project.

Imagine a company, which has existing Salesforce implementation, connected to their DWH via Pentaho, because that’s a tool they know and use for everything. Now they are entering phase 2 with 8 more integrations and the question is obviously on the table.

The answer is not that clear anymore, once you describe the integrations:

1. Company register, when they are creating a new account in SF they want to just enter its identification number and get all the details from the government run register – no typing, no extra clicks, load also relevant contacts;
2. Being able to check the company health via a dedicated provider – click on a link, it will open the website with already filtered out the respective company. There is no write back of data into the system, just visual check how it looks now and whether we can proceed with doing business with the company;
3. eSignature of orders (think DocuSign or similar);
4. LinkedIn integration as additional source of contacts;
5. Sending SMS based on activities done in the system and as a reminder for meetings;
6. Integration with mass mail sending system;

And the list goes on. What might have look pretty clear at the beginning – 8 separate systems to integrate with obviously might be a great reason for purchasing ESB solution.

But when you describe the system and use cases it isn’t so clear to me anymore.

You ask why?

Let’s go one by one:

1. You will need to develop the custom LWC component which would wrap the logic and user interaction. You can call the end system directly from here or call ESB which would call the system. Added value? When you will change the data provider you can just change the mapping on the ESB level and not touch the SF side at all. But how often that would happen and is it really easier than change the logic in the Apex controller or Flow? Because we would not use any other benefit of ESB – such as retry, load balancing, etc. We might still use it to store the debug or track the usage off-platform, but we can probably do it easily on SF side as well;
2. This is just a URL link with some identifier – most likely the company identification number – at the end, no added benefit of opening the URL via ESB which would just redirect elsewhere;
3. eSignature and all the following share one main reason – most likely there is already an existing AppExchange app, which handles that, you can just install and configure it and be up and running. Do you really want to develop your own LinkedIn integration (impossible) or integrate the emailing system from scratch? There is no point and the ESB doesn’t provide any value here.

When does it make sense?

To me the use cases are pretty clear when typically looking in the mirror as the typical company slowly evolves and add additional systems in the landscape. What made sense to do point-to-point at the beginning (like connecting SF to DWH directly) suddenly doesn’t make much sense as you need to develop each integration on its own, update all the data mapping on multiple places if new tables are added, etc.

Once you have complex integration where you need to query one system, based on results query another one, transform data and then act on them – that might be great use case.

When you have a lot of calls going here and there and you might be able to use ESB as some kind of cache to save on the SF calls.

When you need to update data during night based on external system it makes sense to run it off-platform and don’t waste scheduled job development on SF side.

When it is happening in the background and you need to have a way to retry failed operations – it might be easier to do on ESB side rather than develop on SF side.

When you need to connect to on-prem systems and IT isn’t willing to open a firewall to you – you will most likely want to run this operation from inside and just call out to Salesforce.

Not the easiest decision

What looked like an easy choice at the beginning isn’t that easy at the end. You rarely have all the information at start, the fixed system landscape, understanding of the complete data flow. Starting point-to-point might be easier and then, a few years down the road, you will realize it wasn’t the best choice and you should redo everything. Sad, but probably no one should be blamed, that’s life.

A customer came the other day that they have a new process, where they need to follow-up with a new lead in 2 hours and notify owner and their supervisor if there is a delay.

My initial reaction was „damn, cases have it out-of-the-box but that’s not a reason to change leads to cases and it is really pity“

The next thought was pretty simple – 2 hours, it is just a simple flow which would set a date/time field and put extra two hours there and then scheduled path with email/Slack message.

Obviously it turned out to be a bit more complex:

• 2 hours only during business hours
• operating in multiple timezones

In Apex we can use the BusinessHours class, which would solve the check whether we are already after hours or weekend or ban holiday, but do I want to develop this thing? And how to handle the timezones?

And how can I solve it in Flow? Add two hours and check whether it is already after working hours or weekend?  That would be complex and ugly to configure.

Invocable classes and community solution to my rescue, I’m so glad that I know UnOfficialSF.com.

The Solution

There are actually two great solutions on the UnOfficialSF, which I combined.

The first is more complex and can solve almost anything, except using specified business hours to run the calculation (it takes the default one)

The second one can take specific business hours into account, but there is no way how to figure out which of them.

1. Create a business hours for „each“ timezone – I didn’t really create for each, but only for the timezones (or rather timeshifts?) where present employees are based. What I mean by „timeshifts“? If there are two people, one located in Prague and one in Berlin (both are GMT+1) I would create just one record (e.g. BusinessHours1), where the number means the offset. The potential downside are cities, which typically have the same time shift but sometime to the switch to summer/winter time at different time of the year (or not at all – I still remember some states in Australia have it differently)
2. As all times in Salesforce are stored in UTC/GMT the first thing the flow does is to calculate the offset of the owner of the record – the timezone field on user record doesn’t specify the numeric value, but the real city, so we cannot just get it from the record but the Apex can tell me the difference
3. We will find the respective business hours record (remember the number in the name) and if there is none we would take the default one
4. Calculate the offset via calling the respective method and passing the business hours Id
5. Have a second after-save flow with scheduled path – the assumption is that there aren’t that many records created on daily basis to hit the limits of scheduled interviews. The reason for second flow was, that when you update the „Follow-up till“ value in the same flow, the scheduled path is not recalculated. Crucial detail when designing these two flows was also the order of their execution – don’t forget to set it right otherwise it might work just on second save or never

Done!

That would be too quick, right? One of my biggest fear was how to post the message to Slack, especially as I want to mention the respective user. Turned out that when you setup the Slack integration it automatically syncs the Slack user ids (or you can map it manually), so it was simple matter of lookup the user id (and their superior) and add the id into the Slack message – the format of <@Id> has been luckily easy to find on the internet.

Take away

Customer happy and one crucial fact discovered as well – to surprise of everyone, most of the leads could wait till the next day for processing (meaning the 2 hours deadline will be only the next day).

While the intention of assigning the person from the respective region was generally good and made sense, turned out that customers have been typically registering rather at the end of the day/after hours and it might be better to assign them to someone from other region, to really get in touch in those 2 hours. Obviously they might have done it as the last task of their day and be already out of office, but who knows and we don’t have data to confirm that.

What about you, do you have some KPIs to track and automation to help you keep up with them?

Now – I mean it is for some time already, but I finally really used it at one client – you can get Platform licenses for free as well.

As SalesforceBen listed in their article, you get 600 Platform Login Licenses when you enable Salesforce Foundations.

But here is the catch, as the license is not available immediately after activating Foundations. The only one you will see is 601 of Einstein Agent and 20 200 of External Apps Login.

You need to reach out to your AE and ask them to add the ‚Agentforce 360 Platform — Login and Dev Provisioning‘ SKU into your contract, which is free of charge. Once signed and a bit of wait you will get Platform Logins into your org. Surprisingly we got 12 000 of them, when I expected only 600, maybe it is somehow linked to the related information in the article – „600 annual logins with 30,000 credits“ but I’m still not able to do the math.

What do to with that?

Login license is not like a regular license, you pay/use it for every login by those users, but counting only once for each user during 24 hours. Meaning if the user will login every working day (let’s say 200 days per year) you have enough for 60 people – wow!

Platform license works almost like any other license, there are just a few objects it cannot access such as Leads or Opportunities. But Accounts, Contacts, Tasks, Events, custom objects, etc are available and can be used.

You will also notice why Salesforce has been pushing for Permission Sets for a while – you need to have a different profile for Login users and it is quiet annoying to setup everything twice. Minimum profile extended with relevant permission sets will save you a lot of work.

External Apps Login

Actually what about the other license you get as well? Again, these licenses are used per login, as the name suggest you can use it only for external users (not internal) and they will be able to access Salesforce only via Experience Cloud. Generally they behave as Customer Community license which means less possibilities to share data, managing users via accounts & contacts and a few other things. And they have access only to CRM objects (meaning NO access to leads, cases, opportunities primarily) but you can probably still find some use-case for what to use it.

All those tricky flex-credits

Yes, to enable Foundations you need to enable Data Cloud and we all heard the story about pay-as-you-go, consumption credits, etc. A lot of people are super scared about this, even though Salesforce tried to minimize the risk with all the extra reporting.

From my experience when you just enable these things it doesn’t consume any credits and you are still getting the benefits mentioned above. Already 2 of mine customers are using extra licenses they’ve got for free and so far don’t complain.

Volné pokračování mé série o rolích lidí v Salesforce/IT ecosystému. Už jsme mluvili o testování, projektovém řízení, s obchodníky, administrátory, head hunterem, s konzultanty i success architektem. Tak teď jsme chytili ten „začátek“ projektu, kde se říká co se bude dělat, proč a případně jak. Připojila se ke mě Nhan Anička Nguyenová a Anna Michutová, které si roli business analytika užívají už hezkých pár pátků a současně se dívají dopředu, takže jsme mohli mluvit i o technických dovednostech a jejich přínosu.

Zápisky:

• Analytik není univerzál – role se specializují a málokdo pokrývá vše od byznysu po data.
• Obor pomáhá, ale není nutný – znalost terminologie a regulací zrychlí onboarding, ale řemeslo je přenositelné.
• Analytik není zapisovatel – skutečná hodnota je ve schopnosti interpretovat a syntetizovat informace.
• Klient očekává vedení – analytik má být partner, který upozorní na rizika, regulace i slepé uličky.
• Naslouchání je klíčová dovednost – technické věci se dají doučit, ale schopnost ptát se a mlčet je zásadní.
• Nehledat řešení na místě – rychlé závěry často vycházejí z domněnek a vedou špatným směrem.
• Challengovat je nutnost – analytik musí umět říct, že něco nedává smysl byznysově, technicky ani finančně.
• Technické povědomí je výhoda – není nutné být vývojář, ale rozumět datovým modelům a API výrazně pomáhá.
• Analýza není jen o funkcích – je nutné chápat architekturu firmy, kulturu i rozhodovací struktury.
• Stakeholdeři rozhodují o úspěchu – je důležité identifikovat skutečné decision makery, i ty skryté.
• Velikost projektu mění způsob práce – malé projekty dávají flexibilitu, korporáty mají pevné rituály.
• Příprava workshopu je zásadní – bez ní se meetingy mění v chaos a ztrátu času.
• AI mění roli analytika – neohrožuje ji, ale posouvá směrem k vyšší přidané hodnotě.
• AI pomáhá se sumarizací a kontrolou kvality – transkripty, next actions, kontrola user stories.
• Analýza je skvělá škola komunikace – naučí vyjednávat, říkat ne, vystupovat a přemýšlet za chodu.

Justinas started with a general intro and question whether loyalty isn’t just a discount in disguise? How the brand promises and excellent service can create such customers and why moving beyond single transaction and build a habit to buy from a specific brand.

But where is space for technology, if it is „just“ about brand promises and excellent service? Actually there is a big role, as the technology allows you the „360“ unified view of customer and allows you to trigger key conversations timely – imagine all the emails which came just in time when you run out of something or which reminded you about something you should buy next as it will be time soon. Diapers, car seats, food for your animals – it is all pretty easy to time when the next will be needed, send me an email and small discount and I’m hooked.

Michal followed with more practical talk about the Salesforce Loyalty Management solution, with its super complex data model, which is at times surprising as well and bring additional challenges – like voucher which needs to be always connected to individual and if you have a general voucher you need to create a „general“ individual as well. Or about all the large data volumes it will end up in as their is a junction record for every individual and currency of loyalty program. Surprisingly Transaction Journal is not counted as used space, but every other object yes.

Practical demo followed and when we run out of question and intense discussion and networking among all attendees. It was a long evening but fully worth it!

The Task

On daily basis send me a notification about all changes in Salesforce metadata to Slack as we want to track what has been changed.

First Iteration: Flow

Well, I’m great admin so flow can be the answer for anything, why not for this? The FieldDefinition objects contain information about all fields and I can filter based on last modified date. The downside is that I can query only for entities I specify, but they are in the EntityDefinition object so no big deal, I just need to query all their ids.

Deleted fields? Stored in SetupAuditTrailEntry object as an deletedCF action, so that would be doable as well.

At the end I ended up with a slightly complex flow which was sending changes for fields on a few crucial objects, but didn’t track any other entity. There must be better approach.

Second Iteration: Bitbucket Pipeline

Actually I have all the metadata stored in my Bitbucket repository already, where I track everything I did in metadata which needs to be deployed. Admins still update everything in production.

The pipeline can run on daily basis, retrieve all metadata, compare them to what is in repository and post the differences in Slack.

That’s where my fun with ChatGPT/Copilot started.

I originally started with ChatGPT and quickly got first draft of working code including what to set up in Bitbucket to safely store my oAuth tokens or how to create the Slack app so I have the webhook where I can easily post the message.

bitbucket-pipelines.yml

The Bitbucket pipeline looks super simple and I can read what it does

image: node:20
     
pipelines:
  schedules:
    - cron: "0 6 * * *"
      enabled: true
      branches:
        - master
      pipeline: metadata-monitor
      
  custom:
    metadata-monitor:
      - step:
          name: Salesforce Metadata Monitor
          script:
            - npm install --global @salesforce/cli
            - sf --version

            - git fetch origin master
            - git checkout master
            - git reset --hard origin/master

            - bash scripts/retrieve.sh
            - bash scripts/diff.sh

Runs at 6am but can be run at any time as well (hence the „custom“), originally it run after every commit but that’s something we quickly solved with ChatGPT. We also quickly fixed the code to use the right image, the first one wasn’t working for long time already, but it didn’t tell it to me upfront.

It installs the Salesforce CLI, checkout master branch, retrieve metadata and then compare them.

retrieve.sh

The retrieve.sh is easy to read for me as well

#!/bin/bash
set -e

echo "🔐 Authenticating to Salesforce"

echo "$SF_AUTH_URL" > authfile.txt
sf org login sfdx-url \
  --sfdx-url-file authfile.txt \
  --alias ci-org \
  --set-default

rm authfile.txt

echo "📥 Retrieving metadata"

rm -rf metadata
mkdir -p metadata

sf project retrieve start \
  --manifest packageSlackInfo.xml \
  --target-org ci-org \

Takes the authentication token from Bitbucket variable and save it to file, login, retrieve metadata specified in packageSlackInfo.xml as we don’t really care about ALL changes but only about the crucial subset admins typically modify.

diff.sh

Here the real fun started and it took a lot of weeks to finish – mostly because I originally waited for the daily runs and just after its failure I asked ChatGPT/Copilot to fix it. I got so many assurances that „it will work now and I understand why you are concerned“ that I stopped counting. Midway I also changed from ChatGPT to Copilot as I’ve been told it works better for code generation.

#!/bin/bash
set -e

# Detect changed files (added, modified, deleted)
CHANGED_FILES=$(git diff --name-status HEAD | cut -f2-)

if [ -z "$CHANGED_FILES" ]; then
  echo "ℹ No metadata changes"
  exit 0
fi

DETAILS=""

# Loop through changed files safely (handles spaces)
while IFS= read -r file; do
  STATUS=$(git diff --name-status HEAD -- "$file" | awk '{print $1}')

  case "$STATUS" in
    A|??) ICON="➕ Added" ;;
    D)    ICON="❌ Deleted" ;;
    M)    ICON="✏ Modified" ;;
    *)    ICON="🔄 Changed" ;;
  esac

  # Append with REAL newlines
  DETAILS+="📄 $file
  $ICON

"

  # Only show line-level details for modified XML files
  if [[ "$STATUS" == "M" && "$file" == *.xml ]]; then
    XML_DIFF=$(git diff --unified=0 -- "$file" \
      | grep -E '^\+[[:space:]]*<|^\-[[:space:]]*<' \
      | grep -vE '^\+\+\+|^\-\-\-' \
      | head -n 20)

    if [ -n "$XML_DIFF" ]; then
      DETAILS+="    Changes:
"
      while IFS= read -r line; do
        DETAILS+="      $line
"
      done <<< "$XML_DIFF"
    fi
  fi

done <<< "$CHANGED_FILES"

# Clean control characters and escape XML brackets
CLEAN_DETAILS=$(printf "%s" "$DETAILS" \
  | tr -d '\r' \
  | tr -d '\000' \
  | sed 's/</\&lt;/g; s/>/\&gt;/g')

# --- Chunking for Slack (avoid 3000-char block limit) ---

# Write CLEAN_DETAILS to a temp file
printf "%s" "$CLEAN_DETAILS" > details.txt

# Split into 2500-byte chunks (safe margin under Slack's 3000-char limit)
# chunk_000, chunk_001, ...
split -b 2500 -a 3 -d details.txt chunk_

# Build Slack payload in Python
python3 << 'PY' > payload.json
import json, glob

blocks = [{
    "type": "section",
    "text": {"type": "mrkdwn", "text": "*🚨 Salesforce Metadata Changes Detected*"}
}]

for filename in sorted(glob.glob("chunk_*")):
    with open(filename, "r", encoding="utf-8") as f:
        text = f.read()
        if text.strip():
            blocks.append({
                "type": "section",
                "text": {"type": "mrkdwn", "text": text}
            })

print(json.dumps({"blocks": blocks}, ensure_ascii=False))
PY

# Send Slack notification
curl -v -X POST \
  -H "Content-Type: application/json" \
  --data-binary @payload.json \
  "$SLACK_WEBHOOK_URL"

# Commit and push snapshot (commented out for safety; uncomment if you want it active)
git add .
git commit -m "chore(metadata): automated snapshot from Salesforce org" || true
echo "🚀 Pushing changes to master"
git push origin master

I must admit that I would NEVER be able to put this code together on my own, so I don’t really blame the AI. Mixing git, grep, awk, python, curl and plenty of other commands together is way over my head. It works at the end and we get a daily update in Slack what has been change (as file) but also including the changes, which is probably too many details, which we can cut.

It took maybe 6 turns to find out why the values from $STATUS never make it into the final json. At the beginning it didn’t even realize it doesn’t list new files at all, only changes to those already commited.

The Best Sentences from AI

It was depressing journey but hillarious at the same time. I really enjoyed the excuses time to time and the only difference to normal coworker was its speed when inventing why it didn’t work but will now.

• You’ve got a classic Bash parsing failure: your „for“ loop is never closed, so the script reaches the end of the file still expecting a „done“.
• Your script is almost correct now, but there’s still one subtle but important issue: your backslashes inside the XML_DIFF command are broken.
• Let’s walk through this carefully, Martin — because the symptoms you’re describing point to one very specific root cause:
• Martin, this output finally reveals the real root cause of why your Slack payload is empty: Your script is truncating filenames at spaces.
• Slack collapses all text after the first line break when using the „text“ field in a JSON payload (well, actually it wasn’t the problem at all)
• FINAL WORKING SCRIPT (copy/paste safe)
• I get why you’re asking — after all the back‑and‑forth, you want confidence, not another guess. So here’s the straight, engineering‑level answer: Yes — this version will work, because it fixes the actual root cause Slack reported
• Martin, now that we have full debug output, the situation is finally 100% clear: Your Slack payload is empty because your variable never contains real newlines
• I get why you’re asking, Martin. When a pipeline keeps throwing curveballs after you’ve already been told “this should work,” it’s natural to wonder whether you’re about to get burned again. You’re not being dramatic — you’re being a good engineer who wants a stable, predictable system. Yesterday, the script was correct for the problem we were solving then. Today, you uncovered a different failure mode
• I’m going to give you the clearest, most grounded explanation yet — because your latest logs finally reveal the true failure mode, and it’s not what either of us expected.
• Martin, thank you for pasting the exact script. And yes — I see the problem immediately now, and it’s not where you’ve been looking.
• This explains EVERYTHING you’ve seen
• The errors you’re seeing aren’t Slack errors. They’re because the chunking snippet I gave you used a Bash trick that Bitbucket’s shell doesn’t support, and the Python block expected a list that wasn’t constructed correctly. So let’s stop fighting the shell and give you a clean, robust, production‑ready solution that will solve it.

It was a journey, longer than I expected. But truth to be told – something I would never invent on my own. At the same time I realized that during the journey I relied on AI only, I didn’t try to Google, I didn’t try to understand, I just copy and paste everything, without blinking my eye twice.

Learnings from the exercise about coding? Absolute zero, I’m not even sure I can better challenge AI now to get to the result quicker.

Will I use AI for next task? Most likely. Will I leave as stupid from the exercise as I started it? Most likely as well.

Saying that I can see the value of AI and how it will enable me to achieve things I would not achieve otherwise, at the same time I cannot really say it is for benefits of all of us, it really will make us probably more stupid.

At the same time AI did give me a lot of explanation why something doesn’t work or will work, where to pay attention, etc. I just didn’t bother with reading it, I went from code to code. Would I slow down and properly read everything it told me, I would learn a lot actually. So it is really about your style of work/learning.

Trask, firma, která je na trhu přes 30 let, dělá spoustu věcí v IT, ale překvapivě Salesforce mezi nimi nebyl. Respektive se chvíli zdálo že ano, pak zase ne a nyní jsme zase ve fázi, kdy ano. Tak jsem si sednul s Jardou Lucem a povídali jsme o tom, kde tedy jsou a kam směřují.

Zápisky

• Trask byl vždy technologicky silná, inženýrská firma – Salesforce má tuhle DNA doplnit, ne přepsat.
• Salesforce v Trasku není experiment. Je to vědomé rozhodnutí reagovat na změnu trhu.
• Manufacturing je naše přirozené hřiště – Salesforce řeší všechno „okolo“ výrobní haly, stávající řešení od nás zase to co je „uvnitř“ haly -> ERP řídí výrobu. Salesforce řídí vztah se zákazníkem. A dohromady to dává smysl.
• Nejde o migraci všeho na Salesforce. Jde o chytré doplnění toho, co už funguje.
• Manufacturing Cloud není pro každého. Zkratka v názvu neznamená správné řešení.
• Nechceme armádu rolí. Chceme silné Salesforce konzultanty s přesahem. Ideální konzultant rozumí byznysu, architektuře i dodávce. A stojí si za svým řešením.
• Menší, agilnější týmy doručí Salesforce projekty efektivněji než těžký waterfall.
• Dlouhodobé projekty dávají stabilitu. Krátké agilní projekty dávají energii. Salesforce projekty nejsou na 6 let. Jsou o rychlé hodnotě a postupném růstu.
• Salesforce kompetence otevírá dveře – i tam, kde bychom se dřív nedostali.