Giovanni HoSang

If you know me, I like to try to make technical concepts more intuitive and approachable. Here's a bite-sized look at how 𝘁𝗲𝘅𝘁-𝘁𝗼-𝘀𝗾𝗹 works. This is similar technology that powers Salesforce Data Cloud's Einstein Segment Creation functionality, and behind Waii's enterprise products. Notes + Comments (not included in the animation): * Text-to-SQL solutions also often offer semantic layers which help explain the tables being translated against; this allows the service to understand the query request, map it to the existing schema to identify potential matches, and then generate + verify SQL to return the expected results * Security + governance considerations are often handled based on the user providing the utterance... "hey, should Jordan be able to see the things he's asking about?" * Text-to-SQL can be abstracted away into declarative solutions/containers that allows business users to modify without interacting directly with code (similar to the Einstein Segment Creation experience). This abstraction then gets handled on the backend when the query is run. * Steps and processes vary across products. I've chosen to simplify to these - happy to hear feedback from others on what else should be included 🙂 #Salesforce #DataCloud #Agentforce

111

2 Comments

Two years ago, AI didn’t show up once in my FAANG interviews. Today? It’s everywhere, even if you're not interviewing for an AI role. In my last few mocks with engineers prepping for Meta and Databricks, I saw a clear shift: System design questions with AI-powered components Behavioral rounds probing GenAI decision-making How would you build an agent to do X?” is no longer hypothetical I came across this awesome masterclass that deconstructed what AI-ready actually means in 2025 interviews. And it was led by someone who’s lived it: Samwel Emmanuel: https://lnkd.in/g5mC82Kk Ex-Google & Salesforce engineer Now at Databricks building AI-powered data infra Harvard alum + Army reservist (seriously impressive mix) Mentored hundreds into top-tier AI and data roles Here’s what stood out: AI expectations broken down by role: SWE, PM, EM, TPM, Data Hands on demo: building and explaining a working agent—just like you’d do in a real round Interview patterns decoded with brutal clarity FAANG Interviews in the AI Era. Watch Free Here: https://shorturl.at/X63ai If you’re job-hunting in 2025, this is not optional. The candidates who will stand out? They’re not just building with AI. They’re thinking in AI. #FAANG #GenAI #TechCareers #SystemDesign #InterviewPrep #SoftwareEngineering #EngineeringLeadership #InterviewKickstart

9

I have been getting a lot of questions regarding the recent Salesforce article and email about "Changes to Device Activation for Single Sign-On (SSO)." Here is the breakdown of what changed and how to eliminate those extra verification steps for your users. The Change: Salesforce has tightened its security logic. Even with a successful SSO login, if the device is unrecognized and your Identity Provider (IdP) doesn't explicitly signal that strong authentication (MFA) was performed, Salesforce will now intervene. This triggers a ‘Device Activation’ prompt (email/SMS), creating another step for users who expect a seamless login. The Fix: To prevent these interruptions, Admins need to prove to Salesforce that the login is secure. You can do this by checking/updating two configurations: -- Establish Network Trust: Ensure your organization’s IP ranges are listed under Network Access in Setup (or is listed in the allowed IP ranges in users Profiles). This tells Salesforce the login is originating from a safe location, which usually bypasses secondary challenges. -- Configure High Assurance Claims: Check that your IdP is sending the specific Multi-Factor Authentication signals Salesforce recognizes (SAML ‘AuthnContext’ or OIDC ‘amr’ values). This confirms that your IdP has already handled the security check so Salesforce doesn't have to. Full Article: https://lnkd.in/e_BVFh_n

30

1 Comment

A recruiter messaged me last month asking if I was open to a “Salesforce role.” That’s it. That’s the whole message. No Cloud. No role tier. No indication whether they needed someone to reset passwords or redesign a data architecture serving 50,000 users. I stared at it for a solid 10 seconds trying to figure out which of the 200+ Salesforce job titles this person was referring to. Gave up. Closed the message. Here’s the thing: Salesforce is not one product. It’s 7 products, 4 role tiers, and a vocabulary that was apparently designed by people who hate recruiters. Sales Cloud and Marketing Cloud share a name. They share nothing else. An admin and an architect both “do Salesforce.” One costs $80K. The other costs $180K. They cannot do each other’s jobs. Ten recruiters told me this year they follow my content to learn the platform. Ten. That number has been bothering me for months because it means there’s an entire profession responsible for placing Salesforce talent, and nobody’s given them a dictionary. I finally wrote one. The Salesforce ecosystem in plain English. Clouds, roles, salary ranges, the five terms you’re getting wrong in every JD, and three questions that tell you in 60 seconds whether someone is real or memorized a study guide. Part 1 of 10. Free. No email gate. No “download my PDF” nonsense. https://lnkd.in/gmjypQdN

25

7 Comments

The business problems that trace back to a poorly governed Salesforce org are predictable. Salesforce configurations that held up until someone made an undocumented change. Automations that failed silently for weeks before anyone noticed the data was wrong. Integrations running without error handling are considered functional until they aren’t. Over the next two weeks, I’ll break down what we see in the field: the governance failures behind these problems and the disciplines that prevent them. If you manage or inherit a Salesforce org, this is worth following. If you know someone who does, send it their way. Questions in the comments are welcome. I’ll answer what I can. #Salesforce #TechDebt #SalesforceConsulting #EnterpriseIT #VALiNTRY360

8

1 Comment

📢 ServiceNow ($NOW) Earnings Preview — “AI Agents or AI Overload?” ServiceNow reports Q3 earnings this Wednesday, and Wall Street’s watching closely. Analysts expect $4.21 EPS and $3.35B in revenue, but the real story isn’t just growth — it’s whether Bill McDermott’s agentic AI vision is driving profits or draining cash. 💸⚙️ 💡 Highlights: ✅ 20% YoY subscription growth expected ✅ AI workflow adoption + Moveworks acquisition in focus ✅ 2026 CapEx forecast could make or break sentiment 🐂 Bull Case: Seamless execution → stock rebounds toward $1,100+ 🐻 Bear Case: AI fatigue + cost bloat → slide to $850 Read the full breakdown 👇 https://lnkd.in/gRiyK_b3 #ServiceNow #EarningsSeason #ArtificialIntelligence #TechStocks #Investing #AIEarnings #Automation #DigitalTransformation

1

2 Comments

From Admin to DevOps: Your First GitHub Commit with Salesforce + Hutte One of the key principles of Agile software delivery is to frequently deliver working software through incremental changes. In Salesforce, that means pushing both declarative (like Flows or fields) and programmatic (like Apex code) changes to a version control system — usually GitHub. But where do you start if you're an admin with no dev background? Let me walk you through a low-effort, high-impact approach that you can follow along and complete: Hutte + Scratch Orgs + GitHub Step-by-step: Create a GitHub account(Sign up at github.com) You’ll use it to track changes to your Salesforce metadata (like code, flows, and custom objects). Sign-up and log in to hutte.io (30-day free trial available) Hutte connects to your Salesforce Dev Hub and GitHub, giving you a clean, UI-driven interface. Hutte supports a hybrid environment, that is to say that both developers and admins can use it comfortably through the CLI and UI, respectively. Scratch orgs are temporary orgs (expire in 30 days), they promote Source-driven development (SDD). Deploy a scratch org with one click As an admin: ➤ Create a custom object ➤ Add a few fields ➤ Build a screen flow ➤ Add it to a Lightning record page As a developer: ➤ Write an Apex class or trigger View changes in the UI Hutte shows you everything you've done — both declarative and programmatic — and lets you decide what to commit. At a basic level, declarative changes are metadata changes that can be tracked, just as code is tracked. It supports a hybrid environment, that is to say that both developers and admins can use it comfortably through the CLI and UI, respectively. Write a meaningful commit message, this is part of good DevOps hygiene important for collaboration and traceability. Push to GitHub — just like that, your change is now tracked, reviewable, and deployable. Why this matters: This is part of the Software Development Life Cycle (SDLC). There are many other important steps ahead, such as writing and running tests (arguably one of the most critical). While this is one way to deploy changes, there are others, including: ➤Change Sets in sandboxes ➤Salesforce Dev Center ➤CI/CD pipelines using tools like GitHub Actions or Jenkins ➤Other DevOps platforms such as AutoRABBIT, Flosum, Copado, and Gearset. But if you're an admin looking to dip your toes into DevOps, this combo (Hutte + GitHub + scratch orgs) is one of the most intuitive ways to get started. Next, we will incorporate Jira, a project management and issue tracking tool, and see where it fits in the SDLC flow, and also other amazing features of Hutte, such as org pooling. Have fun while doing this 🙂. A link with screenshots is in my Notion: https://lnkd.in/dyyTGm_j #Salesforce #DevOps #SalesforceAdmin #GitHub #Hutte #VersionControl #SalesforceDev #NonprofitCloud #CI/CD

15

As a business grows, a single Salesforce org might no longer fit every region, brand, or compliance need. At that point, the focus changes from “one org or many?” to “how will multiple orgs work for my company?” Once you're on a multi-org path, you need a strategy. Here are the common patterns to consider: 1. Autonomous Orgs Each business unit runs its own Salesforce org with little or no direct integration. This gives maximum independence and lets teams move fast. Best for companies with very different processes or strict data-residency rules. 2. Hub-and-Spoke A central hub org stores and manages common data like Accounts, Contacts, or Products, while Individual orgs (the spokes) handle day-to-day operations. Integration is managed through tools such as Pub/Sub APIs or MuleSoft. Best for organizations that need both local flexibility and a centralised, shared view of customers or products. 3. Global Master with Regional Transactional Orgs A single global org maintains master data, governance, and global automation while regional orgs focus on local transactions, currencies, and compliance. Identity is unified through SSO, and metadata is pushed downstream. Best for enterprises that want tight global control but need to handle regional differences in real time. Choosing the right path is a big architectural decision. It depends on your unique business needs. The key is to understand your business and choose a strategy that works for you. A multi-org setup offers flexibility and scale, but it also brings integration and governance overhead. Plan early to avoid costly redesign later.

4