<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Who Sees What</title>
    <link>https://whoseeswhat.com/</link>
    <atom:link href="https://whoseeswhat.com/rss.xml" rel="self" type="application/rss+xml" />
    <description>Notes from the team building a Salesforce access oracle.</description>
    <item>
      <title>Field-level security: the layer people forget</title>
      <link>https://whoseeswhat.com/blog/2026-07-07-field-level-security-the-layer-people-forget/</link>
      <guid>https://whoseeswhat.com/blog/2026-07-07-field-level-security-the-layer-people-forget/</guid>
      <pubDate>Tue, 07 Jul 2026 00:00:00 GMT</pubDate>
      <description>You can lock down records perfectly and still expose the one field that mattered. Field-level security is the quiet last layer of Salesforce access.</description>
      <category>Salesforce security</category>
      <category>salesforce</category>
      <category>security</category>
      <category>field-level-security</category>
      <category>access</category>
    </item>
    <item>
      <title>Permission sets vs profiles: where over-access usually hides</title>
      <link>https://whoseeswhat.com/blog/2026-07-05-permission-sets-vs-profiles/</link>
      <guid>https://whoseeswhat.com/blog/2026-07-05-permission-sets-vs-profiles/</guid>
      <pubDate>Sun, 05 Jul 2026 00:00:00 GMT</pubDate>
      <description>Profiles and permission sets both grant the same powerful permissions. The difference in how they are managed is where a lot of excess access comes from.</description>
      <category>Best practices</category>
      <category>salesforce</category>
      <category>security</category>
      <category>permissions</category>
      <category>least-privilege</category>
    </item>
    <item>
      <title>Sharing rules: their power, and their risk</title>
      <link>https://whoseeswhat.com/blog/2026-07-03-sharing-rules-power-and-risk/</link>
      <guid>https://whoseeswhat.com/blog/2026-07-03-sharing-rules-power-and-risk/</guid>
      <pubDate>Fri, 03 Jul 2026 00:00:00 GMT</pubDate>
      <description>Sharing rules are how you open Salesforce access sideways. They are also the layer most likely to accumulate quietly until no one can explain it.</description>
      <category>Salesforce security</category>
      <category>salesforce</category>
      <category>security</category>
      <category>sharing</category>
      <category>access</category>
    </item>
    <item>
      <title>Safe with full access, by design</title>
      <link>https://whoseeswhat.com/blog/2026-07-01-safe-with-full-access-by-design/</link>
      <guid>https://whoseeswhat.com/blog/2026-07-01-safe-with-full-access-by-design/</guid>
      <pubDate>Wed, 01 Jul 2026 00:00:00 GMT</pubDate>
      <description>Read-only was never the real reason Who Sees What is safe to connect. The real reason is how it is engineered, and that is what lets the safety story hold even for tools that need to act.</description>
      <category>Salesforce security</category>
      <category>salesforce</category>
      <category>security</category>
      <category>trust</category>
      <category>architecture</category>
    </item>
    <item>
      <title>The role hierarchy is not an org chart</title>
      <link>https://whoseeswhat.com/blog/2026-07-01-the-role-hierarchy-is-not-an-org-chart/</link>
      <guid>https://whoseeswhat.com/blog/2026-07-01-the-role-hierarchy-is-not-an-org-chart/</guid>
      <pubDate>Wed, 01 Jul 2026 00:00:00 GMT</pubDate>
      <description>Salesforce role hierarchies look like reporting lines, so people build them that way. That is where a lot of accidental access comes from.</description>
      <category>Salesforce security</category>
      <category>salesforce</category>
      <category>security</category>
      <category>roles</category>
      <category>hierarchy</category>
    </item>
    <item>
      <title>Org-wide defaults: the floor of your sharing model</title>
      <link>https://whoseeswhat.com/blog/2026-06-29-org-wide-defaults-the-floor-of-your-sharing-model/</link>
      <guid>https://whoseeswhat.com/blog/2026-06-29-org-wide-defaults-the-floor-of-your-sharing-model/</guid>
      <pubDate>Mon, 29 Jun 2026 00:00:00 GMT</pubDate>
      <description>Org-wide defaults are the most consequential access setting in Salesforce, and the easiest to set once and forget. Here is how to think about them.</description>
      <category>Salesforce security</category>
      <category>salesforce</category>
      <category>security</category>
      <category>owd</category>
      <category>sharing</category>
    </item>
    <item>
      <title>Read-only by design: how Who Sees What connects, and what it never touches</title>
      <link>https://whoseeswhat.com/blog/2026-06-27-read-only-by-design/</link>
      <guid>https://whoseeswhat.com/blog/2026-06-27-read-only-by-design/</guid>
      <pubDate>Sat, 27 Jun 2026 00:00:00 GMT</pubDate>
      <description>Before you connect any tool to your Salesforce org, you should know exactly what it can do. Here is the short, honest version for Who Sees What.</description>
      <category>Security</category>
      <category>salesforce</category>
      <category>security</category>
      <category>trust</category>
      <category>data-handling</category>
    </item>
    <item>
      <title>The Salesforce access layers, explained</title>
      <link>https://whoseeswhat.com/blog/2026-06-25-the-salesforce-access-layers-explained/</link>
      <guid>https://whoseeswhat.com/blog/2026-06-25-the-salesforce-access-layers-explained/</guid>
      <pubDate>Thu, 25 Jun 2026 00:00:00 GMT</pubDate>
      <description>Who can see a record in Salesforce is decided by seven layers stacked on top of each other. Here is what each one does, in plain language.</description>
      <category>Salesforce security</category>
      <category>salesforce</category>
      <category>security</category>
      <category>access</category>
      <category>sharing</category>
    </item>
    <item>
      <title>The quiet ways Salesforce access creeps wider</title>
      <link>https://whoseeswhat.com/blog/2026-06-23-quiet-ways-salesforce-access-creeps-wider/</link>
      <guid>https://whoseeswhat.com/blog/2026-06-23-quiet-ways-salesforce-access-creeps-wider/</guid>
      <pubDate>Tue, 23 Jun 2026 00:00:00 GMT</pubDate>
      <description>Access in Salesforce almost never shrinks on its own. Here are the everyday mechanisms that widen it, usually without anyone deciding to.</description>
      <category>Salesforce security</category>
      <category>salesforce</category>
      <category>security</category>
      <category>access</category>
      <category>sharing</category>
    </item>
    <item>
      <title>How to answer &apos;who can see this record?&apos; in five minutes</title>
      <link>https://whoseeswhat.com/blog/2026-06-23-who-can-see-this-record-in-five-minutes/</link>
      <guid>https://whoseeswhat.com/blog/2026-06-23-who-can-see-this-record-in-five-minutes/</guid>
      <pubDate>Tue, 23 Jun 2026 00:00:00 GMT</pubDate>
      <description>The question sounds simple and the manual answer is anything but. Here is the fast way to get a complete, defensible answer.</description>
      <category>Best practices</category>
      <category>salesforce</category>
      <category>access</category>
      <category>how-to</category>
    </item>
    <item>
      <title>Introducing Who Sees What</title>
      <link>https://whoseeswhat.com/blog/2026-06-22-introducing-who-sees-what/</link>
      <guid>https://whoseeswhat.com/blog/2026-06-22-introducing-who-sees-what/</guid>
      <pubDate>Mon, 22 Jun 2026 00:00:00 GMT</pubDate>
      <description>A read-only way to answer the question every Salesforce admin eventually gets asked: who can see this, and why?</description>
      <category>Announcements</category>
      <category>salesforce</category>
      <category>security</category>
      <category>launch</category>
    </item>
  </channel>
</rss>
