rossbelmont

Populating Credentials with the Connect API

Introduction and Purpose

The purpose of this unofficial document to illuminate how developers and skilled system administrators can achieve a high level of automation when deploying Named Credentials to one or more Salesforce orgs by combining packaging with Connect API methods designed to support this use case.

The expanded Connect API is needed to reach this goal because the current state of the Metadata API and packaging do not support moving shared secrets or sensitive values like API keys between orgs. Doing so would necessitate retrieving the secret value from the org in clear text before deploying it to the target org; this is not workable from a security and trust point of view.

So although packaging is unlikely to address this completely, it can be part of the solution. Customers can package a Named Credential and External Credential and deploy them to one or more orgs, then use the Connect API in a minimal way to populate the sensitive values.

rossbelmont

Product Brief or “Thesis” - Template

What are the target scenarios or “struggling moments?”

• Moment A
• User Flow B
• Scenario C

Examples

When (situation or circumstance), I want to (motivated action), so I can (successful outcome).

When the prospect has agreed to the basic terms of the deal, I want to send the quote for electronic signature, so I can count the deal as closed with a signed contract.

rossbelmont

.DS_Store

rossbelmont

Potential bug in the Metadata API

Here's a note from one of our customer-facing architects:

I'm trying to load external credentials as metadata. Apparently, I can not push metadata that has a perm set and header all at once. I have to delete the perm set from the metadata for it to work. If I then resubmit the original metadata, it’s successful.

I have to do it twice, which is a bummer — deployment fails and I have to manually intervene.

rossbelmont

Minimal IAM Permissions • Salesforce Connect adapter for Amazon Athena

The following represents a configuration of minimal IAM permissions needed to support the Salesforce Connect adapter for Amazon Athena. Specifically, this example uses a separate (dedicated) workgroup for Salesforce Connect to use with Athena, as well as specific S3 buckets containing the relevant source data.

This limits access to business data while providing enough access to metadata to make configuration easier for administrators. Note the following items in ALL_CAPS that will need to be replaced in your configuration:

• ACCOUNT_ID: ID of the AWS Account containing all the above resources (e.g. 467032906895)
• AWS_REGION: Geographical region containing the S3 bucket used by the workgroup (e.g. us-east-1)
• BUCKET_1_NAME: name of the S3 bucket used to house the source data
• BUCKET_N_NAME: included for instructional purposes in case Athena reads from multiple buckets
• RESULTS_BUCKET_NAME: name of the S3 bucket used by

rossbelmont

rossbelmont

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Assign_Rating</members>
        <name>QuickAction</name>
    </types>
    <types>
        <members>privateConnectDemo2022022402</members>
        <name>OutboundNetworkConnection</name>
    </types>

rossbelmont

{
  "columns": {
    "fullName": {
      "virtual": "true",
      "values": [{
        "definition": "FirstName+\" \"+LastName"
      }]
    }
  }
}

rossbelmont

{
  "tableLocation": {
    "catalog": "AwsDataCatalog",
    "database": "mydb"
  },
  "tableName": "works_of_art",
  "extendedQualifiers": {
    "workgroup": "primary"
  },
  "keyColumns": [

rossbelmont

{
  "tableLocation": {
    "catalog": "AwsDataCatalog",
    "database": "works_of_art"
  },
  "tableName": "artwork",
  "extendedQualifiers": {
    "workgroup": "primary"
  },
  "keyColumns": [