, because they allow me to access the same development environment from virtually anywhere. Recently I was looking at using the AWS CLI within my Codespace and found it really easy to do so. Here are the few simple steps it takes:

GitHub Codespaces require a GitHub Organization account. In the organization account settings, find "Codespaces secrets" under Secrets > Codespaces. Here you can store encrypted environment variables that can be used within Codespaces.

Use AWS_DEFAULT_REGION, AWS_ACCESS_KEY_ID, and AWS_SECRET_ACCESS_KEY as names for the secrets.

Now to make the AWS CLI available within the terminal of your Codespace, edit the file .devcontainer/Dockerfile of your repository. If this file doesn't exist yet, you can use the "Add Development Container Configuration Files" option of VS Code.

Add the following lines to the Dockerfile to make the AWS CLI available within Codespaces:

After you edit the Dockerfile, Codespaces is offering to rebuild the container, which you should do. After that, AWS CLI will be available and thanks to the Codespaces Secrets we set up earlier, there's no need for further configuration.

Using AWS CLI within GitHub Codespaces

Newsletters are all the rage right now, and I see many startups launch products around newsletter publishing while existing players like Twitter are also getting into the space. At the same time, lots of people with existing audiences (e.g., on Twitter) start building up mailing lists, and there's also a ton of people starting in this space from scratch.

When thinking about the various newsletters I see and that I'm subscribed to, I see a set of distinctive types that one could categorize them into:

This type of newsletter is typically published frequently (monthly or weekly, some even daily) and summarizes the news in a specific field, often with links to more detailed articles and sometimes with some commentary. This could be technical (like 

 with updates around the React ecosystem which I follow) or just world news like published in the 

Those newsletters are often very much tied to a personality, and most of the time, they're even named after their author. They allow subscribers to follow the author's journey through private and/or professional life. Some focus on the professional aspects like projects, learning, and new insight; others have a more personal touch and include things like travel or even personal life events. One of the most popular newsletters in this category is the best-selling author 

Every email represents a proper article. This is probably a good summarization of the idea behind long-form editorials, which offer are mostly published infrequently and, for me, are very similar to many blogs: A collection of well thought out and carefully edited articles or essays which go beyond the pure collection of links or summarization of news and announcements. An example in this category would be 

, where Lenny Rachitsky publishes insightful posts about product management and growth strategy.

The promise of these newsletters is mainly that they're easy to consume as they're short and mostly consist of a few links and insights. I've mentioned Tim Ferriss already, but he actually runs a second newsletter called 

 which is named brilliantly in my opinion as the title gives you an excellent idea of what to expect: Five little tidbits in your inbox every Friday.

This is the classical email list to keep customers or potential customers up to date on developments in the company or new product features and releases. I'm, for example, subscribed to the 

 newsletter, where they just this week announced that they're working on a brand new product called "Reader."

All the above types of newsletters have the same dynamic in terms of publishing: New emails are sent to all subscribers on a more or less regular basis, and as soon as you sign up, you'll be amongst the people receiving the next issue published. However, recently I see some people setting up formats that are inspired by a marketing technique called "drip campaigns," where people are put on an email journey which then sends a sequence of prepared emails starting with the day that people enter this journey (in the case of newsletters by signing up for the newsletter). This concept lends itself to scenarios where authors teach something or want to guide their subscribers through a pre-defined journey or experience stretching over several weeks. Examples of this would be 

, who, in addition to his weekly newsletter, offers productivity training via such an email journey or 

Six Popular Types of Newsletters

Sometimes I create slides to visualize concepts just for a specific meeting or context and later think that this could be useful for a broader audience. I'm determined to share the results of my work more broadly wherever possible and put my blog to good use for that.

This is a representation of the **different tools available in Salesforce to design user access to data**. As this visualization is quite different from all the content about this topic that I've seen so far, I thought it's worthwhile to put it out there:

A user has exactly one profile and one role, additionally, they can be assigned to one or multiple territories and/or public groups.

A record on the other side has exactly one owner and has a bunch of field values (e.g. an account could have an "Industry" picklist, an opportunity has a "Stage" assigned, and so on).

The most basic method of data access is ownership - if you're the owner of a record, you have access to it. Yay! Building onto this is the Role Hierarchy, which basically enables you to give access to records to everyone above the owner using a hierarchical structure.

An alternative (or addition, if you want) to the Role Hierarchy is using territories. Records (accounts, to be exact) are assigned to territories based on certain field values (e.g. all accounts from the "Financial Services" industry could be assigned to the "Financial Services" territory and/or all accounts with more than 1,000 employees could be assigned to the "Enterprise Customers" territory). You then assign users to those territories, which gives those users access to the accounts (and related data, based on further configuration) in the respective territories.

Probably the most flexible way to give users access to records is via Sharing Rules. As always, great power comes with great responsibility, which in this case means there are some things to consider when making extensive use of Sharing Rules, especially with regards to handling performance and managing complexity. Sharing rules can be bases either on record ownership or on field values and can grant access to roles, public groups, or individual users.

All the tools described above are about giving users access to specific records. There's one important precondition to that, which is also depicted in the diagram although it's a bit grayed out because it's a different scope: Before a user gets access to records, they need to have access to the object in general and specific fields on an object. So while record access for example determines which accounts you get access to, your Profile (as well as additional Permission Sets) needs to grant you access to the account object in general and determine which fields on the account object you may read and potentially edit.

Design User Access to Data in Salesforce

The Salesforce product portfolio keeps growing, both through new product launches and company acquisitions. Combine this with the product rebrandings happen from time to time and it get's really hard to keep track. With this post I aim to give an overview of the current state (and naming) of the Salesforce product portfolio. I'll try to keep this up to date. 

The current status of this post reflects the situation at the time of publishing on January 5, 2021.

The initial product of the company, hence the name Salesforce.

[Steelbrick acquisition](https://techcrunch.com/2015/12/23/salesforce-grabs-quote-to-cash-vendor-steelbrick-for-360-million/) in 2015, previously called CPQ & Billing. Configure, price and quote capabilities as well as subscription management and billing as an add-on to Sales Cloud.

Sales Cloud add-on for efficient inside sales.

Bundle of artificial intelligence capabilities for Sales Cloud.

Formerly known as Field Service Lightning.

 in 2021, before they were acquired by Salesforce in 2013.

Initially based on Thunderhead through an OEM partnership, replaced by the 

Formerly known as Einstein Analytics formerly known as Wave.

 in 2016. Formerly known as Anywhere, formerly known as Quip. Yes, they renamed it in 2020 and then reverted the renaming in 2021.

2021-01-05

Salesforce Product Names and Acquisitions

Sales

Sales Cloud

Revenue Cloud

High Velocity Sales

Sales Cloud Einstein

Inbox

Maps

Service

Service Cloud

Digital Engagement

Service Cloud Einstein

Field Service

Marketing

Marketing Cloud

Pardot

Social Studio

Interaction Studio

Experience

Experience Cloud

Commerce

B2C Commerce Cloud

B2B Commerce Cloud

Tableau

Tableau CRM

Tableau Online

MuleSoft

Salesforce Industries

Health Cloud

Manufacturing Cloud

Communications Cloud

Utilities Cloud

Other

Heroku

Quip

myTrailhead