Lightningアプリケーションビルダーとコンポーネントの表示設定についてです。
アクセスするユーザの情報を条件にコンポーネントの表示・非表示をアプリケーションビルダー側の設定で制御できます。
条件指定はこんな感じ。(※アプリケーションページの場合)
クライアントを選択するとデバイスの種別も条件に指定できました。
レコードページの場合は項目の値を条件指定できます。またレコードページの場合にはクライアントによる条件指定はできないみたいです。
↧
SFDC：Lightningアプリケーションビルダーとコンポーネントの表示設定
↧
SFDC：Winter'19で新規および変更されたApex処理
メソッドが新規追加された既存の Apex クラス
Schema.DescribeFieldResult クラス
isAiPredictionField()
Einstein 予測データを表示するように項目が有効化されているかどうかを示す Boolean を返します。
Schema.DescribeFieldResult F = Opportunity.StageName.getDescribe(); System.debug(F.isAiPredictionField());
Schema.DescribeSObjectResult クラス
getRecordTypeInfosByDeveloperName()
関連付けられたレコードタイプに API 参照名を照合する対応付けを返します。
Schema.DescribeSObjectResult d = Account.sObjectType.getDescribe(); System.debug(d.getRecordTypeInfosByDeveloperName());
Schema.RecordTypeInfo クラス
getDeveloperName()
このレコードタイプの API 参照名を返します。
RecordType rt = [SELECT Id,Name FROM RecordType WHERE SobjectType='Account' LIMIT 1]; Schema.DescribeSObjectResult d = Schema.SObjectType.Account; Map<Id,Schema.RecordTypeInfo> rtMapById = d.getRecordTypeInfosById(); Schema.RecordTypeInfo rtById = rtMapById.get(rt.id); System.debug(rtById.getDeveloperName());
System.Crypto クラス
verify(String algorithmName, Blob data, Blob signature, Blob publicKey)
指定アルゴリズムと供給された公開鍵を使用して、暗号化されたデータのデジタル署名を確認する Boolean を返します。
verify(String algorithmName, Blob data, Blob signature, String certDevName)
指定アルゴリズムと certDevName に関連付けられた公開鍵を使用して、データのデジタル署名を確認する Boolean を返します。
verifyMac(String algorithmName, Blob input, Blob privateKey, Blob macToVerify)
指定アルゴリズム、入力データ、非公開鍵、MAC アドレスを使用して、データの HMAC 署名を確認する Boolean を返します。
System.Url クラス
getOrgDomainUrl()
組織の正規 URL を返します。
System.debug(System.Url.getOrgDomainUrl());
メソッドが変更された既存の Apex クラス
System.UserInfo クラス
getSessionId()
非同期 Apex (一括処理、future、Queueable、またはスケジュール済み Apex) で getSessionId() を使用できるようになりました。以前は、このメソッドは非同期実行時に null を返していました。
非同期 Apex では、このメソッドはコードが有効なユーザによって実行されている場合にのみセッション ID を返します。コードが内部ユーザ (自動化プロセスユーザやプロキシユーザなど) によって実行されている場合、このメソッドは null を返します。
変更された Apex Enum
Winter '19 リリースでは、次の列挙が更新されています。
Auth.Auth.VerificationMethodEnum Enum
ユーザがログイン時に自分自身を識別できるさまざまな方法が含まれます。モバイルで使いやすいパスワードなしのログインページの実装や、検証方法のセルフ登録 (および登録解除) のために使用できます。
この Enum に新しい値 Password が追加されました。パスワードで ID を確認できます。
Metadata.PlatformActionListContextEnum Enum
アクションリストの各種コンテキストを説明します。
この Enum に新しい値 ActionDefinition が追加されました。この値は、将来の使用のために予約されています。
新規 Apex 例外
Winter '19 リリースでは、次の例外が導入されています。
Auth 名前空間
LoginDiscoveryException
例外を発生させて、ログイン検出ハンドラを実行しているときにエラーが発生したことを示します。
DiscoveryCustomErrorException
ログイン、検証、およびセルフ登録ページに表示するエラーメッセージをカスタマイズするための例外を発生させます。
新規 Apex インターフェース
Winter '19 リリースでは、次の新規インターフェースが導入されています。
Auth.ConfigurableSelfRegHandler インターフェース
ユーザ名とパスワードの代わりにメールアドレスまたは電話番号でユーザを登録するには、Auth.ConfigurableSelfRegHandler を実装するクラスを作成します。設定可能なセルフ登録ページでコミュニティのセルフ登録を設定すると、Salesforce によってデフォルトの AutocreatedConfigSelfReg Apex クラスが生成されます。このクラスを修正して機能を拡張し、ユーザが作成される方法の変更などを行うことができます。
createUser(accountId, profileId, registrationAttributes, password)
コミュニティのセルフ登録ページで訪問者が提供した情報を使用して、コミュニティメンバーを作成します。
Auth.LoginDiscoveryHandler インターフェース
ユーザ名とパスワード以外の確認方法に基づいてユーザのログインを行うには、Auth.LoginDiscoveryHandler を実装するクラスを作成します。ユーザはメール、電話番号、または統合 ID やデバイス識別子などの他の識別子を使用して、自分自身を識別できます。ログイン検出ページでコミュニティのログインページを設定すると、Salesforce によってデフォルトの AutocreatedDiscLoginHandler が生成されます。このクラスを修正し、シングルサインオン (SSO) のサポートの追加などを行うことができます。
login(identifier, startUrl, requestAttributes)
メールや電話番号などの識別子が指定された外部ユーザのログインを行います。成功した場合、開始 URL で指定されたコミュニティページにユーザをリダイレクトします。
System.Callable インターフェース
開発者が共通インターフェースを使用して、異なるパッケージ内のコードでも Apex クラスまたはトリガ間の疎結合インテグレーションを作成できます。共通インターフェースについて合意することで、異なる会社や異なる部署の開発者が相互のソリューションに基づいてソリューションを作成できます。コミュニティの規模を拡大し、当初の予定とは異なるソリューションが必要になる場合、このインターフェースを実装してコードの機能を拡張します。
call(action, args)
他のクラスまたはパッケージで利用したり作成時の基盤としたりできる機能を提供します。
変更された Apex の SOAP API コール
runTests() コールが変更されました。
RunTestsResult オブジェクトに次の 2 つの新規項目が追加されました。
flowCoverage
フローを実行したテスト実行の結果の配列。
flowCoverageWarnings
フローを実行したテスト実行によって生成された警告の配列。
↧
↧
SFDC：apex:iframeタグと$IFrameResourceの使い方
Visualforceページでirameを埋め込むときにはapex:irameタグが用意されていますが、iframe を使用した信頼されないサードパーティコンテンツの参照したいときのために$IFrameResourceという呼び出し方が用意されているみたいです。
https://developer.salesforce.com/docs/atlas.ja-jp.pages.meta/pages/pages_resources_iframe.htm
使い方の例はこちら。
<apex:iframe src="{!$IFrameResource.TestHtml}" id ="theiframe" width="500" height="500"/>
↧
SFDC：Lightning地図コンポーネントの作成を試してみました
Lightningコンポーネントの開発でGoogleマップを呼び出したいときのためにlightning:mapタグが用意されています。
Lightning 地図コンポーネントと Apex の継承された共有の使用 単元 | Salesforce Trailhead
Towerオブジェクト作成
カスタムオブジェクトで作成。取引先と主従関係で紐付く。緯度経度の情報を登録するカスタム項目を用意。
テストデータを作成
取引先に２つのテストデータを作成。
取引先に紐付く形で、Towerオブジェクトのレコードを作成。
Apexクラス作成
TowerMapUtilClass
public class TowerMapUtilClass {
public static List<sObject> queryObjects(String theObject, List<String> theFields, String theFilter, String sortField, String sortOrder) {
String theQuery = 'SELECT ' + string.join(theFields, ',');
theQuery += ' FROM ' + theObject;
if(!String.isEmpty(theFilter)) {
theQuery += ' WHERE ' + theFilter;
}
if(!String.isEmpty(sortField)) {
theQuery += ' ORDER BY ' + sortField;
if(!String.isEmpty(sortOrder)) {
theQuery += ' ' + sortOrder;
}
}
return database.query(theQuery);
}
}TowerMapControllerClass
public class TowerMapControllerClass {
@AuraEnabled
public static List<Tower__c> getAllTowers() {
String theObject = 'Tower__c';
List<String> theFields = new List<String>{'Id', 'Name', 'State__r.Name', 'Tower_Location__Latitude__s', 'Tower_Location__Longitude__s'};
String theFilter = '';
String sortField = 'Name';
String sortOrder = 'ASC';
List<Tower__c> allTowers = TowerMapUtilClass.queryObjects(theObject, theFields, theFilter, sortField, sortOrder);
return allTowers;
}
}Lightningコンポーネント作成
Towermap
<aura:component implements="flexipage:availableForAllPageTypes" controller="TowerMapControllerClass" access="global" >
<aura:attribute name="mapMarkers" type="Object" access="PRIVATE" />
<aura:attribute name="markersTitle" type="String" access="PRIVATE" />
<aura:handler name="init" value="{!this}" action="{!c.handleInit}"/>
<aura:if isTrue="{!!empty(v.mapMarkers)}" >
<!-- Create lightning:map here -->
</aura:if>
</aura:component>コントローラ
({
handleInit: function (component, event, helper) {
helper.initHelper(component, event, helper);
}
})ヘルパー
({
initHelper : function(component, event, helper) {
helper.utilSetMarkers(component, event, helper);
},
utilSetMarkers : function(component, event, helper) {
let action = component.get("c.getAllTowers");
action.setCallback(this, function(response) {
const data = response.getReturnValue();
const dataSize = data.length;
let markers = [];
for(let i=0; i < dataSize; i += 1) {
const Tower = data[i];
markers.push({
'location': {
'Latitude' : Tower.Tower_Location__Latitude__s,
'Longitude' : Tower.Tower_Location__Longitude__s
},
'icon': 'utility:Tower',
'title' : Tower.Name,
'description' : Tower.Name + ' Tower Location at ' + Tower.State__r.Name
});
}
component.set('v.markersTitle', 'Out and About Communications Tower Locations');
component.set('v.mapMarkers', markers);
});
$A.enqueueAction(action);
}
})lightning:mapタグ埋め込み
<!-- Create lightning:map here -->
<lightning:map mapMarkers="{! v.mapMarkers }" markersTitle="{!v.markersTitle}" zoomLevel="5" />
あとはLighntingアプリケーションビルダーでLightningページを作成してLightningコンポーネントを追加すればGoogleマップでTowerの位置情報を表示できます。
↧
SFDC：Lighntingコンポーネントのリファレンスサイト
Lighningコンポーネントを開発するときの参考サイトが用意されています。
カルーセルとか便利なコンポーネントのサンプルもありました。
たぶんコピペで動かすことができると思います。
Lightning Web Componentのサンプルもありました。
↧
↧
SFDC：LEXでも動くVisualforce&Apex開発のサンプルコードを作ってみました
Lightning Experienceでも動くVisualforce&Apex開発のサンプルコードを作ってみました。Lightning Design SystemとAngularJS 1をつかったサンプルコードになります。
Javascirpt Remotingベースの開発について
Salesforce Platform上での開発はVisualforceとApexを使った開発になります。またVisualforceといえばapexタグという独自タグでの開発になります。このapexタグによる開発は2015年にSalesforce1モバイルが登場したときにモバイルページ向けの画面開発ではあま推奨されなくなりました。
そしてLightning Experienceは基本的にはSalesforce1モバイルと同じ考え方で開発が必要になると思います。過去にJavascriptを中心にVisualforce開発を行うための情報も公開されていました。
2015年にはLightning Design SystemというCSSフレームワークが公開され、Lightning Experienceのデザインに合わせた画面開発が可能になっています。
↧
SFDC：Pardotメモ
Pardotの歴史
2012年 Salesforce社が買収
その他
●機能について調べたいとき
ナレッジ・ベース
http://help.pardot.com/customer/ja/portal/articles/
◆Pardot 101
https://sfdc.co/Bcqpl
◆Pardot グロッサリ
https://sfdc.co/bvYdvn
◆トラブルシューティングの質問
https://sfdc.co/bt9jlG
●テクニカルサポート
・ベーシックサポート
・プレミアサポート ※有償プラン
●サービス提供ステータス
http://trust.pardot.com
●Pardotコミュニティ
http://bit.ly/pardot123
↧
SFDC：Pardot導入時の初期設定手順のメモ
Pardot導入時の初期設定手順のメモ。(知らなくても基本的には開発ベンダーに作業依頼して対応してもらえると思う。)
Pardotの概要
Salesforce社のマーケティング・オートメーションツール。
- ホームページに訪れた履歴
- 顧客の興味度の点数化
- 顧客に適したページ表示
- メール配信自動機能
Pardot初期設定の流れ
- Salesforceコンテクターの設定
- テクニカル設定 (初期設定)
- ユーザ/プロスペクト作成
- メールテンプレート送信社リスト作成
- 顧客にメール送信
※シナリオを作成して自動化とかいろいろ機能あるけど、ひとまずメール送信できればPardotの運用開始できる感じ。
PardotとSalesforceを連携させるメリット
- マーケティング部門と営業部門の連携の強化
- メルマガ誤配信の工数削減とリスク回避
- 顧客獲得の経緯をCRM上で把握できる
- 受注になった案件ときっかけとなったマーケティング施策がつながるので分析が用意
Salesforceコネクタの設定の流れ
Salesforceでの設定
- Pardot AppExchangeの設定
- パッケージをインストールするだけ
- Salesforce内の項目の対応付け(取引先責任者とリード)
- Pardot用項目に対してリードの取引開始の割り当て設定
- SalesforceでPardotデータを表示
- ページレイアウト設定で項目を追加
- 権限の割り当て
- プロファイル設定とか権限設定とか。
Parrdot側の設定
- Salesforceコネクターを追加
- PardotのADMIN設定で設定
- カスタム項目の対応付け
- 取引先責任者やリードにカスタム項目がある場合はPardot側に対応するカスタム項目を作成
※重要: Key項目がメールアドレスからCRM IDになった。
同期の時間とタイミング
【同期の時間】
- レコードの変更は、2〜4分以内にPardotとSalesforceの間で同期
- 大量のレコードを同時に更新する場合はすべての変更の同期が完了するのに時間がかかることがある。
【Pardotによる動機のトリガ】
- プロスペクトのアクティビティ
- フォームの登録
- ランディングページの登録など
- ユーザのアクション
- プロスペクトのインポート
- プロスペクトの項目の変更
- システムのアクション
- Salesforceキャンペーンへの追加
- オートメーション、完了アクションによるレコードの変更
【Salesforceによる同期のトリガー】
- リード/取引先責任者の所有者変更
- リード/取引先責任者の項目変更
- リード/取引先責任者のレコード作成
テクニカル設定
- トラッキングコードの設定
- CNAMEの設定
- メール認証設定
トラッキングコードの設定
トラッキングコードとはビジターやプロスペクトのアクティビティを記録するためのツール。自社Webサイトにコピペで設置するだけで設定完了。
(Webサイトごとなど細かくトラッキングコードを用意できる)
CNAMEの設定
自社のDNSにサブドメインのCNAMEレコードを設定。Salesforceの外側の設定。サポートに問い合わせしても対応してもらえないやつ。
メール認証設定
自社のDNSにSPFレコードもしくはDomainkeysレコードを登録。これもSalesforceの外側の設定。一応動画資料に手順書あり。
ユーザー設定
- ユーザーの作成
- ユーザは何件でも作成できる
- ユーザーロールの設定
- 各ユーザのアクセスレベルを制御するための設定。
- Salesforceのロールのような柔軟なカスタマイズ性はなかった。
- ユーザーの一括作成
- CSVファイルのインポート機能で一度に最大50件まで作成できる。
プロスペクト/リスト設定
- プロスペクトの作成
- 手動作成
- CSVファイルのインポート
- CRM経由
- リストの作成
- Pardotの設定で作成
- リストにプロスペクトを追加
- Pardotの設定 / Salesforceのレポート / キャンペーンメンバーとかから追加できる。
Pardotのメール送信
メール設定のプロセス
- リスト選定
- メールテンプレート作成
- メール送信
- メール送信結果の測定
メールテンプレートはHTMLメールにすることになる。ヘッダーやコンテンツ画像の用意が必要。
メール送信結果の確認はリストメールレポートで見れる。基本的にはSalesforceのレポートのような複数レコードの一括分析ではなく、レコードの詳細ページのような一つのメール送信結果に対して分析を行う。
※メール開封率などを分析できる
ライフサイクルレポートで下記の結果を確認できる
※ライフサイクルレポートとはマーケティングレポートと売上レポートをまとめたもの。新規商談数や商談成約件数を分析できる。
初期設定とメール送信と分析機能のイメージはこんな感じ。
↧
SFDC：PardotとMarketoの比較メモ
PardotとMarketoの比較メモです。どっちが良い？と聞かれてSalesorce社の製品なのでPardotが良いです！と答えたのですがさすがにそれじゃあ通らないのでちゃんとPardotのメリットを考えてみたときのメモです。(あくまで個人的な見解なので導入検討時には営業の人に詳しく教えてもらってください。)
あと、このメモつくったあとにPardotのより具体的なメリットと特徴をSalesforce社の営業とのミーティングで教えてもらったのでその当たりはまた他の記事でまとめる予定。
Pardotのメリット
①導入時の初期設定がシンプル
- Salesforceコンテクターの設定
- テクニカル設定 (初期設定)
- ユーザ/プロスペクト作成
- メールテンプレート送信社リスト作成
- 顧客にメール送信
↑ここまで行ったあとにシナリオつくって自動化とかMA的なことをやるための設定が必要になりますが、ひとまずこれだけでメール送信を開始できます。
②操作しやすい。
- ユーザがやりたい施策を短期間で開始しやすい。
- 設定作業時の負担が減る。
③Salesforceとの親和性が高い。
- 2012年からSalesforceの製品
- Sales Cloudとの連携強化が期待できる
- SalesforceとPardotで双方向の同期が可能
- 同期間隔は2から4分 (大量件数の一括更新の場合はもう少し時間が掛かる)
Pardotとマルケトを比較するときの考慮点
・マルケトはデータ連携も組織に合わせてある程度自由に設定できる。
・価格はPardotの方が少し安いが、価格での比較はあまり重要では無い。
・機能数だけで比較すると確実にマルケト。ただしPardotは機能数でマルケトに劣るが問題ないと思う。
■Pardotとマルケトの機能面での差について
①Pardotはリード、取引先責任者、商談としか連携できない。
・メール送信の自動可という意味では上記３つのオブジェクトと連携できればやりたいことはほぼ実現できる。カスタムオブジェクトの値を直接見に行くことはできないが数式などで参照は可能。(もしできなくてもApexトリガなどで値のコピーで対応できる)
②Pardotは「B to B」がターゲット
・C向け顧客をターゲットしているMAツールは「Marketing Cloud」と別製品になるが、メルマガ配信や通常のメール送信作業に関してはPardotで問題なく対応可能。(※個人取引先サポートされてる)
・マルケトのC向け機能のプッシュ通知をアプリに組み込むという点ではアプリ側の開発でカバーできるはず。
・SalesforceのC向けのMarketing CloudはメディアサービスやECサイトを運営しているような企業向けだと思う。
Pardot とマルケトの比較メモ
■費用
・Pardotの方が少し安価
■機能性
・マルケトの方が多機能
【補足】
・メール送信だけではなくプッシュ通知の機能がある。
・LiNEなど連携可能
・API連携もあり (PardotはPlusプランから)
■操作性
・Pardotの方がUIがわかりやすい
■Salesforceとの連携性
・基本同じぐらい
【補足】
・Pardotの場合は双方向の同期が可能
・Pardotの機能で用意されたEngagement HistoryをつかえばSales Cloudユーザに顧客のアクティビティログを活動履歴のような感じで表示できる。
・PardotとSalesforceデータのマッピングはメールアドレスではなくCRM ID。
■データ連携の拡張性
・マルケトの方が組織に合わせたカスタマイズが可能
【補足】
・Pardotは取引先責任者、リード、商談との連携のみ可能。
・マルケトはカスタムオブジェクトを含む好きなオブジェクトをデータ連携で使用できる
→※マルケトはデータ連携を行うためにDB設計が必要
■B to C対応
・マルケトは「B to C」もターゲットに含む
・Pardotは「B to B」がターゲット
【補足】
・Pardotでもメール送信は「B to C」顧客に対して問題なく使用できる
・マルケトが持つC向け機能をSalesforce製品で実現する場合はMarketing Cloudが対象製品。ただし価格は高め。
■サポート
・おそらくどちらも同じくらい
【補足】
・高いサポートを受けたい場合はプレミアサポートに入る (Pardotとマルケト両方あった)
■Salesforce との親和性
・Pardotの方が高い。
【補足】
・PardotはSalesforce社の製品なのでさすがに高いと思う。
・ただマルケトは他システムとの連携が協力なので基本的にはこの部分で困らないと思う。
■分析機能
・マルケトの方が充実している
【補足】
・Pardotのプランを「Plus」にするとB2B Marketing Analyticsが使えるようになってPardot側も少し良くなる。
・B2B Marketing AnalyticsはAnalytics Cloudの一部の機能を利用できるイメージ
■データのキー項目
Pardot = CRM ID
マルケト = メールアドレス
※Pardot もメールアドレスだったけど、変わったらしい。
■初期導入のしやすさ
・Pardotの方が導入時の初期設定の作業がシンプル
【補足】
・マルケトはカスタムオブジェクトを含む様々なデータとある程度自由に連携できる分、初期設定でDB設計等やることが多い。
・Pardotもリードや取引先責任者に項目追加したり、レイアウト追加したり、権限追加したりとかぐらいは発生する。
■営業ユーザに対しての利便性
・どちらもMAツールの項目をSalesforce上に表示できるので同じぐらいだと思う。
■Twitter で教えてもらった感想
【Pardotの良いところ】
・操作性良い。
・価格も気持ち安い
・SalesCloudとの連携も強化されていくと思う。
【マルケトの良いところ】
・シナリオ設計しやすかった。
Pardotの良いところがまとめられていた記事
たぶん唯一Pardotの方がおすすめ！ってまとめてくれていた記事です。
関連記事
↧
↧
SFDC：Dreamforce2018に参加しました - Day 3
現地時間の9/27 (木) - Dreamforce 2018のDay 3です。この日はMarriott Marquisホテルに用意された会場を観に行きました。
会場を一目見ておくのが目的で長いする予定はなかったのですがちょうどField Serviceのセッションが始まるところだったので観ていきました。
Field Serviceのモバイルアプリがあるのですがそちらの紹介がメインの内容となっていました。
地図や作業員ごとのスケジュールをアプリで確認できるみたいなので導入の際には便利そうなアプリでした。
セッション終了後はモスコーニの方に移動しました。もっと奥の方にも会場があったのですが、確かセッション会場だけと思って観に行きませんでした。もしかするとブースとかのスペースが用意されていたかもしれません。
モスコーニ移動後はDeveloper Forestのセッションを観に行きました。1つ目はIBMのAPIに関するセッションです。
APIマネジャーなどの機能があるツールに関するセッションでした。
セッション後はSalesforceのブースに行って話を聞きました。比較的わかりやすそうなLightning Desing Systemの人にお話を聞きました。
まずLightning Design SystemのサイトにリダイレクトするURLがあるみたいです。(イベント期間中だけ利用可能な可能性もあるかも)
getslds.com
VisualforceでLighnting Design Systemを利用している話からlightningStylesheets="true"で有効化できる話になりました。apex:sldsタグよりも強調していたのでもしかしてバージョンアップして同じ意味になったのかなと思ったのですが、よくよく確認するとlightningStylesheetsはapexタグのコンポーネントをSLDSのスタイルに変える目的と確認できたのでやはり使い分けは必要そうでした。
続いてモスコーニウエスト2Fのセッションルームで開催されるセッションを観に行きました。1つ目に観たのはEvent Monitoringに関する話でしたがこちらはあまり頭に入ってきませんでした。途中で退出してMobile Keynoteのセッションを観に行ってみました。
こちらのセッションはスライドでの説明が多く理解しやすかったです。また内容的にも知りたかった情報が多いセッションとなりました。
特に興味深い部分ですがSalesforceモバイルアプリが近日バージョンアップされるとのことです。
一番うれしいのはレコードページにLightning Componentを埋め込める部分かなと思います。今まで以上にカスタマイズの幅が広がりそうでした。またパイロット版のモバイルアプリの利用が可能となっています。
続いてすぐとなりで開催されていたヘルスケアに関するセッションも観てみました。事前情報でHerokuをつかったシステムの話ということと登壇される方が著名な方と聞いて行ってみました。セッション予約時点では人数制限がかかっていましたが問題なく入ることができました。
セッション開始前に参加者にHerokuピンバッチのプレゼントがありました。
この時点で12時40分頃、13時に始まるDeveloper Keynoteのために移動しました。
けっこう前の方に座ることができました。Keynoteの内容ですが技術的なことに絞るとこんな感じ。
Winter’19 Lightning Developer Toolの新機能
Winter'19 Herokuの新機能
force:recordDataタグ追加 ※リアルタイム連携
新しいSandbox組織 "Lightning Developer Pro"の追加 ※5分で作れるSandbox
Lightning Platform
Mule Soft
Einstein
Developer Keynoteで抑えておきたい部分はこんな感じでした。このKeynoteが終わったタイミングで14時30分頃、お昼のランチセットを探しに行ったのですがさすがに終了してました。
会場近辺で入りやすそうなお店を探したところ良さげなお店を見つけました。
Mixtというサラダがメインのお店です。
入ってみるとサブウェイ方式で自分で選んでいくスタイルだったのですが、決まった組み合わせのプレートメニューもあったのでなんとかなりました。
またこの時点でDreamforce Questもコンプリートできました。
午前中に行ったセッションでコンプリート要件を満たしていたはずが、なぜかクリア扱いにならないトラブルに遭遇しました。別のセッションにもう一度行かないと・・・と考えていたところ、モスコーニウエスト1FにあるDreamTheaterとかかれたヘルプデスクに相談するとチェックしてもらえるとという情報を聞き、カウンターで見てもらったことでクリアとなりました。(同じ問い合わせが結構はいっている雰囲気でした。)
これでCodeyのぬいぐるみをゲットできました。
このあともセッション等見る予定だったのですが、疲れが溜まってきたので荷物を置くついでにホテルに戻りました。17時20分頃に会場にもどりましたがブラブラしただけで特に何もせずに過ごす感じとなりました。
Day 3でKeynote系のセッションがすべて終了となります。そのため日本語通訳レシーバーの返却が本日までとなっている雰囲気でした。営業時間が19時まででしたのでDeveloper Keynoteが終わったタイミングで返却しておきました。Day 3はこんな感じで過ごすことができました。
↧
MEMO：THE MODEL(ザ・モデル)を読んでみました
Twitterで話題になっていたTHE MODEL(ザ・モデル)のKindle版を読んでみました。
マーケティングオートメーションに興味があったときに、マルケト社の代表の方が書いた本ということで気になって買ってみました。(あとセールスフォースって単語も少し出てたので)。マーケティングオートメーションや営業プロセスの話がわかりやすく説明されていてすごくよかったです。また、マルケト社の日本法人設立の話とその頃のオラクル、セールスフォース、マルケト、サンブリッジの関係もわかる話もあって面白かったです。
序文ではサンブリッジ代表の方の話も載っていました。オラクルで勤務していた時にセールスフォースを創業する前のマーク・ベニオフと一緒に働いた話やオラクルの日本法人の代表の方から、著者の福田さん(マルケト社の代表の方)を紹介された経緯などが紹介されていました。その他、米国と日本でフィールドセールスのコストの違いがあるなど営業プロセスの話や当時のクラウドサービスについての話もありました。
本文では著者の方がマーク・ベニオフとの出会いや、オラクル→セールスフォース→マルケトと勤務していったときのことを詳しく書いていました。セールスフォースの話がけっこう詳しく出てたのでその辺りの内容も楽しめました。
読んでみて印象に残った内容
- 当時の業務ソフトウェアの話
- 膨大な初期投資が必要で、手間も時間も掛かるというのが当時の常識。セールスフォースが目指していたのはソフトウェアを便利なサービスとして手軽に利用できるような世界。
- SMB企業の重要性
- CRMやSFAについての概要
- 営業プロセスについて
- マーケティング、インサイドセールス、フィールドセールスの分業体制について
- プロセスをシステムで管理するメリット
- インサイドセールスの考え方
- リードプロセスの話
- リードの考え方、リードの育成、適切なタイミングで訪問営業することの重要性
- リード獲得とコストの話
- マーケティングオートメションツールの重要性
- なぜ必要なのか、何を実現するのか
- マルケトとの出会いの話も
知ることができてよかった内容
リードプロセスについての話が参考になりました。Salesforceでリードオブジェクトと取引先オブジェクトを使い分けるときにリードオブジェクトは見込み客とあいまいな定義でしか認識していませんでしたが、この本のリードプロセスの考え方を読んで、リードオブジェクトはこうやって使おうというイメージが固まった気がします。
マーケティングオートメーションのツールも、メール送信が自動化やメール開封率などでスコアリングできるツールで分析や作業が楽になるツールぐらいのイメージでしたが、リードプロセスや営業プロセスに組み込むことで効果があるということを理解できた気がしました。
まだ流し読みしただけなので、細かい部分は何度か読まないと覚えられなさそうですが、リードやMAについてこういう考え方をすれば効果を出せるという内容を知ることができてすごく参考になる書籍でした。
Kindle版
書籍版
↧
SFDC：Sales CloudとWeb会議システム
いつか必要になったときのメモ。ベルフェイスがSalesforceとの連携のベータ版を公開。遠距離などで訪問が難しい場合にWeb会議システムの仕組みがあると便利かも。Salesforce内からベルフェイスを起動すると活動の記録に自動で登録される。
ベルフェイスだと、相手にツールをインストールしてもらう必要は無いので便利。音声は電話。
↧
SFDC：ページレイアウト設定で項目の権限を一括変更する方法
特定のページレイアウトで項目の権限を参照のみや必須と権限設定するのは項目にマウスを当てたときに表示されるレンチアイコンからできます。
複数項目の権限を一括変更したいときは、項目選択時に「command」+クリック(Macの場合)で複数選択できるのでその状態でレンチアイコンをクリックすると一括変更できます。
複数選択
一括変更
一つずつ設定変更していくのは時間がかかるので覚えておくと便利です。
↧
↧
SFDC：Spring'19 新機能ウェブセミナーPlatform編を見てみました
Trailblazer Communityでウェブセミナーの録画版リンクが共有されていたので見てみました。資料と動画のリンク自体はヘルプページで共有されているみたいです。
リストビューの固定
ビューの右側にピン固定のアイコンが表示されるようになったのでクリックすると次からそのビューが最初に表示されるようになります。
レコードページの印刷
Lightning Experienceでも主要なオブジェクトで印刷ボタンが使用可能になりました。
- 取引先/個人取引先
- 取引先責任者
- リード
- 商談
- ケース
- 注文
- 契約
- キャンペーン
- カスタムオブジェクト
ページレイアウトに追加することで利用可能です。外部に見せるようなデザインではありませんが、社内ミーティング用としては問題なさそうです。
データストレージのデフォルト容量の変更
今まではデフォルトでは1GB利用可能でしたが10GBまで利用できるようになりました。2月から順次有効化されていくとのことです。また基本的にはほぼ有効化が完了しているとのことでした。Developer Edtionでは5MBが上限のままでした。(元がいくつか思い出せないけどたぶん変更なし..)
グローバル検索の結果数表示
検索対象オブジェクトごとに、検索結果を数字で表現できるようになったそうです。たぶん赤枠で囲った部分。
Lightning Excpeirnceのヘルプメニューのカスタマイズ
システム管理者は各ページのメニュー上部に最大15個の独自のリンクを追加できるようになったそうです。設定で有効化することで利用可能になります。
Lightning Experienceでの感謝バッジの使用
LEXではサポートされていなかったWork.comの機能が利用できるようになります。現在はパイロット版でSalesforceに問い合わせて利用可能になります。
Lighnting Experienceの有効化(Winter’20から)
Winter'20で本格的に移行が促されます。今までも自動切り替え等実施されてきましたが、今回は本格的なやつだと思います。こちらに公開されているファイルが詳しいみたいです。
Chatterの新機能
Lightning Experineceで投稿・コメントへのリンクの挿入
Chatter投稿時に「/」を宣言するとレコードリンクが埋め込めるようになりました。URLの投稿と違いレコード名が変更されると投稿内容の方にも変更が反映されます。
SalesforceモバイルアプリでのChatterの編集・ミュート
モバイルアプリで編集やミュートができるようになりました。特に編集機能は便利だと思います。
レポート&ダッシュボードの新機能
実行ページからデータをより容易に確認
Winter'19でベータ版として提供されていましたが、レポートの実行ページが新しくなりました。(旧バージョンには戻せないそうです)
画面下のラジオボタンで小計などのオン・オフを切り替えたり、項目がたくさん表示されていてもスクロールできれいに表示されて便利だと思います。ただテキストエリア項目の表示領域が狭くなって不便になっています。この問題はKnowledge Issueとして登録されているので近い内に解決されるのではと思います。
その他の便利な新機能としてはこんな感じ
- 集計項目を8つまで表示可能
- レポートの実行ページでグループ化や列の削除などの操作が可能
- 列幅の変更が可能
- Lightningレポートビルダーでの結合レポートの作成
- 条件付き書式(ベータ)が使える
- ダッシュボードコンポーネントを12列のグリッドに配置することが可能
- ダッシュボードでユーザ、グループまたはロールの一括登録
- ダッシュボードで1行表示可能に
残りの新機能メモ(ざっくりこんな話でした)
Einstein予測ビルダー
→アドオン製品(追加ライセンス)
Einstein Next Best Action
→おすすめを表示するコンポーネントが利用可能に
Flow Builder
→より迅速かつ簡単に
Lightningアプリケーションビルダーでページテンプレートを変更
→アプリ単位でホームページの割り当て
Sandboxのコピーが正式リリース
Lightning Webコンポーネントの追加
Mobile Publisher
→日本語未対応
→アドオン製品
個人的に特に便利だったのがLightningアプリケーションビルダーでページテンプレートを変更の機能です。活動や関連リストを表示する場合は、ヘッダーと右サイドバーに統一してるので気軽に変更できるようになってすごく助かりました。
Sandboxのコピーはあまり使う機会が無い気がしますが、メインのSandboxをリフレッシュするときにその時のバックアップを残したりできるのは便利そうです。
Mobile PublisherとEinstein Next Best Actionは用語から把握してなかったのでそういうものがあると気づけてよかったです。
その他参考リンク
最近読めてないけどホントはリリースノート読まないといけない...
↧
SFDC：ToDoの詳細ページと完了としてマークボタン
Spring'19からと思いますが、ToDoの詳細ページに完了としてマークボタンが表示されるようになっていました。(前からあって意識してなかっただけかも...)
クリックひとつでToDoのステータスを完了に変更できます。
ページレイアウト設定での追加は不要です。また除外はできないみたいです。
ToDoの登録とステータス管理を活用するとレポートで何件のタスクをこなしているかと作業漏れにも気づくことができるので便利です。
↧
SFDC：PardotのAppExchangeインストールページのリンク
PardotのAppExchangeインストールページのリンクです。AppExchangeサイトで検索すればいいかと思っていましたが専用のページが用意されていました。
AppExchangeかどヘルプか思い出せないけど、そこからインストールしたら古いバージョンがインストールされたらしくてインストールし直すハメに・・・。
↧
SFDC：レポートのバケット機能の制限について
レポートのバケット機能は特定の値でグルーピングできる便利な機能です。ただし件数には上限があり、それを超えると下記のエラーが発生します。
「これらのバケットのクエリが複雑すぎます。1 つ以上のバケットを削除して再試行してください。」
検索するとヘルプページがヒットします。
(ヘルプページ自体は404になってましたが...)
基本的には上限を超えてバケットを作成しようとするとエラーメッセージが表示されます。
設定欄の追加ボタンも上限に達したタイミングで非表示になります。
ただ、設定方法によっては稀に保存ボタンをクリックしたタイミングで制限を超えていることに気づいてエラーとなることがあるみたいで、その場合頑張って設定した時間が無駄になってしまうのでバケット作成には上限があることは設定前に把握しておくのがよさそうです。
関連
↧
↧
SFDC：取引先の都道府県を選択リスト型に変換する機能を試してみました
取引先の都道府県を選択リスト型に変換する機能を試してみました。設定の「州/国/テリトリー選択リスト」で有効化できます。
有効化前はテキスト型となっています。
有効化の流れ
1. 州/国/テリトリー選択リストを設定します。
まずはデフォルトの国と選択値の有効/無効を設定します。
業務上必要な国のみ参照可能にしておくのが良さそうです。
保存するとこんなメッセージが表示されます。
国名の左側にある編集リンクをクリックするとラベルの変更や州の追加ができます。
州とありますが日本で登録するのは都道府県になります。
州コードには都道府県コードを登録できます。都道府県コードは検索すると一覧が見つかると思います。
登録するときに使わせてもらったのはこちら。
47都道府県を手動で登録するのは面倒...という場合はメタデータAPIで登録できます。
開発者ガイドはこちら。
メタデータAPIによる登録方法はよくわかっていないので今回は手動で頑張りました。
2. 組織をスキャンします。
スキャン機能で既存データの影響度をチェックできます。
スキャンが完了するとメールが届きます。メール内のリンクをクリックすると「3. データを変換します。」のページに移動できます。
3. データを変換します。
スキャン後は国の値の変換作業を行います。今まで自由入力だったものが決まった値になるので過去データの変換作業です。
変更したい値にチェックをつけて変更後の値を指定します。
変更リストに保存のボタンをクリックすると対象として扱われます。国ごとにひとつずつやっていく必要があるみたいです。
すべて選択すると次へボタンが表示されます。次へ進むと州の変換ページに移動します。
先程、州登録をしていればだと思いますが日本の都道府県も選択できます。
国と同じようにすべて選択すると完了です。
最後に有効化の確認ページが表示されます。「完了して選択リストを有効化」を選ぶと処理が開始されます。
以上が都道府県を選択リスト化するときの流れです。
取引先ページを見に行くと無事に選択リスト形式に変換されていました。
過去データの方も特に影響はありませんでした。また国と都道府県にテキストのみという項目が追加されるみたいです。
↧
SFDC：州/国/テリトリー選択リストとApexを試してみました
州/国/テリトリー選択リストを有効化するとApexで国や州のコードも取得できるようになります。例えば下記のような感じです。
SELECT Id, Name, BillingCountry, BillingCountryCode
,BillingState, BillingStateCode FROM Account
取得が可能。ということで登録も可能か試してみました。
List<Account> accounts = new List<Account>(); // 都道府県コードで作成 Account account1 = new Account( Name = 'テスト取引先1' ,BillingStateCode = '10' ); // 都道府県の値で作成 Account account2 = new Account( Name = 'テスト取引先2' ,BillingState = '愛知県' ); // リスト追加 accounts.add(account1); accounts.add(account2); // 登録 insert accounts;
下記のように都道府県コードでも都道府県の値でもどちらでも問題なく取得可能でした。
選択リスト型になるのでリスト値取得できるかと試してみました。Codeの方にするとリスト値が取得できるようです。
Schema.DescribeFieldResult F = Account.BillingStateCode.getDescribe();
List<Schema.PicklistEntry> P = F.getPicklistValues();
for (Schema.PicklistEntry pick : P) {
System.debug(pick.getLabel() + ':' + pick.getValue());
}
実行結果はこちら。
取得できる順番はあいうえお順になってしまうのでちょっと不便そうでした。州/国/テリトリー選択リストとApexについてはこんな感じです。
参考
↧
SFDC：Apex開発とシステムエラー発生時の対応について
Apex開発するときに個人的に重要と思っているのがシステムエラー発生時の検知についてです。下記のようにエラーメールを管理者に送信するようにすると予期せぬトラブルやシステムのバグにすばやく対応が可能になります。
こうした機能を実装するときは「try-catch」処理を使用します。
try {
// 処理
} catch(DmlException e) {
// DMLエラー発生時の処理
} catch(Exception e) {
// システムエラー発生時の処理
}
エラー発生時のメッセージは下記のような感じで取得できます。
// DMLエラーメッセージ e.getDmlMessage(0); // Exceptionエラーメッセージ e.getMessage();
よく見る実装方法として下記のような書き方が見られます。
try {
// 処理
} catch(DmlException e) {
System.debug(e.getDmlMessage(0));
} catch(Exception e) {
// システムエラー発生時の処理
System.debug(e.getMessage());
}
System.debug処理でログを表示する方法です。システム開発中や不具合発生後の検証用途としては良いのかもしれませんが、通常の運用時ではユーザもシステム管理者もエラーに気づくことができないと思われます。(下手をするとシステムエラーが発生しているのに正常系として実行されてしまいます。)
そこで下記のようなメール送信処理を用意して対応します。
※クラス名は『CommonEmail』としています。
/**
* Exceptionエラーメールの本文取得
*/
private static String getSendExceptionEmailBody(String message, Exception e) {
String errorMsg = message;
errorMsg += '\n';
errorMsg += '実行ユーザ名: ' + UserInfo.getUserName();
errorMsg += '\n\n';
errorMsg += e.getTypeName() + ' ' + e.getMessage();
errorMsg += '\n';
errorMsg += e.getStackTraceString();
return errorMsg;
}
これをcatch処理内で次のように呼び出します。
} catch(DmlException e) {
CommonEmail.sendEmailByExceptionError(e);
errorMessage = e.getDmlMessage(0);
return errorMessage;
} catch(Exception e) {
CommonEmail.sendEmailByExceptionError(e);
errorMessage = '申し訳ございません。処理中にエラーが発生しました。';
return errorMessage;
}
これでシステムエラー発生時にシステム管理者に対してどのクラスの何行目の処理でエラーが発生しているかが細かく通知されます。ユーザIDも表示しておけばどのユーザが処理に失敗して困っているかも確認できます。
return処理でエラーメッセージを返すようにしてそれを画面に表示すればユーザ側にも処理が失敗したと通知ができます。Exceptionエラーを表示するとユーザに親切ではなくなってしまいますが、DmlExceptionエラーのメッセージならユーザにある程度親切なメッセージを表示できます。
DmlExceptionは標準カスタマイズ側の入力規則エラーメッセージもcatchして表示できます。特定の入力規則エラーが頻繁に発生している場合はデータ登録ページのUXの見直しをするといった判断にも使用できます。
以上がApex開発とシステムエラー発生時の対応についてです。こうした例外系の対応もしておくようにするとSalesforceで構築したシステムの品質が向上すると思います。
関連
↧