Salesforce
Benutzerdefinierte Einstellungen
Suche…
Bemerkungen
Einführung
Im Gegensatz zu benutzerdefinierten Objekten, auf denen Datensätze basieren, können Sie mit benutzerdefinierten Einstellungen benutzerdefinierte Datensätze in Ihrer gesamten Organisation verwenden oder bestimmte Benutzer oder Profile anhand von benutzerdefinierten Kriterien unterscheiden. Dies bedeutet beispielsweise, dass Administratoren benutzerdefinierte Hierarchieeinstellungen bearbeiten können, um die Workflow- / Validierungsregeln für einzelne Benutzer oder Profile zu deaktivieren, ohne sie für die gesamte Organisation ausschalten zu müssen (siehe das obige Beispiel Verwenden von benutzerdefinierten Hierarchieeinstellungen zum Deaktivieren von Workflow- / Validierungsregeln) ).
Validierungsregeln müssen normalerweise vorübergehend deaktiviert werden, wenn:
- Der Code aktualisiert alte Datensätze, die zuletzt bearbeitet wurden, bevor eine Validierungsregel aktiviert wurde. Daher erfüllen sie nicht die Kriterien der neueren Regel.
- Der Code fügt neue Datensätze ohne die von den Kriterien einer Validierungsregel erforderlichen Werte ein.
Workflowregeln müssen normalerweise vorübergehend deaktiviert werden, wenn:
- Sie würden eine E-Mail-Benachrichtigung oder ein Feld-Update auslösen, wodurch die Änderungen, die Sie an dem Datensatz vornehmen, überschrieben oder beeinträchtigt werden.
Die Verwendung einer benutzerdefinierten Einstellung gibt Administratoren eine gewisse deklarative Kontrolle über den Code, sodass einer der vielen Anwendungsfälle die Verwendung von Code überflüssig machen kann, um Trigger zu deaktivieren (siehe das obige Beispiel Verwenden von benutzerdefinierten Hierarchieeinstellungen zum Deaktivieren von Apex-Code ).
Ein entscheidender Vorteil für Entwickler ist, dass die Daten der benutzerdefinierten Einstellungen im Anwendungscache verfügbar gemacht werden. Dies ermöglicht einen effizienten Zugriff ohne die Kosten für wiederholte Abfragen an die Datenbank. Diese Daten können dann von Formelfeldern, Validierungsregeln, Flows, Apex und der SOAP-API verwendet werden - siehe die Salesforce-Dokumentation .
Die Grenzwerte und Überlegungen für benutzerdefinierte Einstellungen werden hier dokumentiert.
Benutzerdefinierte Einstellungen auflisten
Sie können auch benutzerdefinierte Listeneinstellungen erstellen. Zu den häufigsten Anwendungsfällen gehören das Speichern von Statuskürzeln mit zwei Buchstaben, internationale Vorwahlen sowie Katalognummern für Produkte. Salesforce fördert jedoch jetzt die Verwendung benutzerdefinierter Metadatentypen anstelle von benutzerdefinierten Einstellungen für Listen.
Wenn Sie eine neue benutzerdefinierte Einstellung erstellen, wird die folgende Meldung angezeigt
Tipp: Verwenden Sie für die App-Konfiguration benutzerdefinierte Metadatentypen
Wenn Sie benutzerdefinierte Listeneinstellungen verwenden möchten, sollten Sie stattdessen benutzerdefinierte Metadatentypen verwenden. Im Gegensatz zu benutzerdefinierten Einstellungen für Listen können Sie die Datensätze benutzerdefinierter Metadatentypen mithilfe von Paketen oder Metadata-API-Tools migrieren.
Benutzerdefinierte Metadatentypen bieten zusätzliche Vorteile gegenüber benutzerdefinierten Listeneinstellungen, wie in dieser Antwort beschrieben . Laut dem führenden Entwickler von CMDs "Es ist viel mehr für benutzerdefinierte Metadatentypen geplant als benutzerdefinierte Einstellungen für Steroide."
Benutzerdefinierte Einstellungen erstellen und verwalten
Schaffung
Um eine benutzerdefinierte Einstellung zu erstellen, gehen Sie zu:
Klassisch
Setup> Entwickeln> Benutzerdefinierte Einstellungen> Neu
Blitz
Setup> Benutzerdefinierter Code> Benutzerdefinierte Einstellungen> Neu
Erstellen Sie Ihre Einstellung (die Unterschiede zwischen benutzerdefinierten Einstellungen für Hierarchie und Liste finden Sie weiter unten in diesem Dokument.) Sie können die Auswahlliste für Sichtbarkeit ignorieren, es sei denn, Sie planen, Ihre Einstellung in einem verwalteten Paket bereitzustellen.
Um Ihre Einstellungsfelder zu erstellen, klicken Sie auf die Schaltfläche Neu und befolgen Sie den üblichen Vorgang zum Erstellen eines benutzerdefinierten Felds.
Verwaltung
Nachdem Sie Ihre Felder erstellt haben, können Sie mit der Konfiguration der Einstellungen beginnen, indem Sie auf die Schaltfläche Verwalten klicken.
Es ist einfacher, die Einstellung zu verwalten, wenn Sie eine neue Ansicht erstellen und alle von Ihnen erstellten Felder einschließen, um auf einen Blick einen umfassenden Überblick über die Einstellung zu erhalten. Der Setup-Besitzer ist der Benutzer oder das Profil, für das die Einstellung gilt.
Um die Einstellung auf Organisationsebene zu verwalten, klicken Sie auf die Schaltfläche Neu über der Überschrift Standardwert der Organisationsebene (in rotem Feld unten).
Um die Einstellung auf Benutzer- oder Profilebene zu verwalten, klicken Sie im blauen Feld unten auf die Schaltfläche Neu.
Benutzerdefinierte Hierarchieeinstellungen verwenden, um Workflow- / Validierungsregeln zu deaktivieren
Benutzerdefinierte Einstellung
Feld für benutzerdefinierte Einstellungen
Feldwert für benutzerdefinierte Einstellungen
Wenn das Feld markiert ist, wird die Validierungsregel für den laufenden Benutzer oder in diesem Beispiel sein Profil deaktiviert.
Die Regel kann auch für eine gesamte Salesforce-Organisation deaktiviert werden.
Validierungsregel
AND(
/* the below is the reference to the Val_Rule_Cntrlr__c custom setting's checkbox field All_Opportunity_Disabled__c
*/
$Setup.Val_Rule_Cntrlr__c.All_Opportunity_Disabled__c = FALSE,
/* the below is the remainder of the validation rule's formula
*/
CloseDate < TODAY()
)
In der obigen Regel müssen beide Kriterien auf TRUE
ausgewertet werden, damit die Regel ausgelöst werden kann.
Da All_Opportunity_Disabled__c
Kontrollkästchen All_Opportunity_Disabled__c
auf TRUE
ausgewertet wird, wenn das Profil des All_Opportunity_Disabled__c
Benutzers All_Opportunity_Disabled__c
ist, wird die Regel als FALSE
ausgewertet.
Workflow-Regeln
Der gleiche Ansatz kann angewendet werden, um die Workflowregeln zu deaktivieren.
Benutzerdefinierte Hierarchieeinstellungen verwenden, um Apex-Code zu deaktivieren
Erläuterung
In diesem Beispiel wurde ein einfacher Auslöser erstellt, um das Abschlussdatum einer Opportunity, die gerade eingefügt oder aktualisiert wird, auf ein Datum zu ändern, das 10 Tage in der Zukunft liegt.
Das Kontrollkästchen der benutzerdefinierten Einstellungen für Apex Controller ermöglicht das Deaktivieren des Codes auf Benutzer- / Profil- / Organisationsebene.
Apex-Klasse
trigger CloseDateUpdate on Opportunity (before insert, before update) {
Id userId;
Apx_Cntrlr__c userApexController;
Boolean userSetting;
userId = userinfo.getUserId();
userApexController = Apx_Cntrlr__c.getInstance(userId);
userSetting = userApexController.Close_Date_Update_Disabled__c;
if (userSetting == false) {
for(Opportunity opp : Trigger.new) {
opp.CloseDate = date.today().addDays(10);
}
}
}
Gerätetest
@isTest
public class CloseDateUpdateTest {
@testSetup
static void dataSetup() {
Profile p = [SELECT Id FROM Profile WHERE Name = 'System Administrator' LIMIT 1];
User u = new User(LastName = 'Test',Alias = 't1',Email = '[email protected]',Username = '[email protected]',ProfileId = p.Id,TimeZoneSidKey = 'America/Denver',LocaleSidKey = 'en_US',EmailEncodingKey = 'UTF-8',LanguageLocaleKey = 'en_US');
insert u;
}
static testMethod void testCloseDateUpdateEnabled() {
User u = [SELECT Id FROM User WHERE Username = '[email protected]'];
// set the custom setting field to FALSE so that the trigger is not deactivated
Apx_Cntrlr__c apexController = new Apx_Cntrlr__c(SetupOwnerId = u.Id,Close_Date_Update_Disabled__c = false);
upsert apexController;
Opportunity[] opportunities1 = new Opportunity[]{};
test.startTest();
system.runAs(u){
for(integer i = 0; i < 200; i++) {
opportunities1.add(new Opportunity(
Name = 'Test Opp ' + i,
OwnerId = u.Id,
StageName = 'Prospecting',
CloseDate = date.today().addDays(1),
Amount = 100));
}
insert opportunities1;
}
test.stopTest();
List<Opportunity> opportunities2 = [SELECT CloseDate FROM Opportunity];
for(Opportunity o : opportunities2){
system.assertEquals(date.today().addDays(10), o.closeDate, 'CloseDateUpdate trigger should have changed the Opportunity close date as it was not disabled by the apexController custom setting');
}
}
static testMethod void testCloseDateUpdateDisabled() {
User u = [SELECT Id FROM User WHERE Username = '[email protected]'];
// set the custom setting field to TRUE to deactivate the trigger
Apx_Cntrlr__c apexController = new Apx_Cntrlr__c(SetupOwnerId = u.Id,Close_Date_Update_Disabled__c = true);
upsert apexController;
Opportunity[] opportunities1 = new Opportunity[]{};
test.startTest();
system.runAs(u){
for(integer i = 0; i < 200; i++) {
opportunities1.add(new Opportunity(
Name = 'Test Opp ' + i,
OwnerId = u.Id,
StageName = 'Prospecting',
CloseDate = date.today().addDays(1),
Amount = 100));
}
insert opportunities1;
}
test.stopTest();
List<Opportunity> opportunities2 = [SELECT CloseDate FROM Opportunity];
for(Opportunity o : opportunities2){
system.assertEquals(date.today().addDays(1), o.closeDate, 'CloseDateUpdate trigger should not have changed the Opportunity close date as it was disabled by the apexController custom setting');
}
}
}
Benutzerdefinierte Hierarchieeinstellungen in Apex-Code aktualisieren
Möglicherweise möchten Sie Ihre benutzerdefinierten Einstellungen während der Ausführung Ihres Codes aktualisieren, um die Validierungs- oder Workflowregeln auszuschalten.
Im folgenden Code habe ich eine Schedulable Apex-Klasse erstellt, die das Abschlussdatum aller Opportunities aktualisiert, deren Abschlussdatum weniger als oder gleich 6 Tage ab dem aktuellen Datum liegt, wodurch das Datum auf 20 Tage in der Zukunft geändert wird.
Ich werde meine benutzerdefinierte Einstellung Val_Rule_Cntrlr__c verwenden, um alle Validierungsregeln zu deaktivieren, die mich daran hindern, die Opportunitys zu aktualisieren, die meine Kriterien erfüllen.
global class Scheduled_OppCloseDateUpdate implements Schedulable {
global void execute(SchedulableContext SC) {
updOpportunityCloseDates();
}
global void updOpportunityCloseDates() {
Id userId;
Val_Rule_Cntrlr__c setting;
Boolean validationRulesAlreadyDisabled;
List<Opportunity> processedOpps = new List<Opportunity>();
Date d;
// get running user's Id
userId = userinfo.getUserId();
// retrieve Custom Setting status, for running user
setting = Val_Rule_Cntrlr__c.getInstance(userId);
// if the setting field is false, update it to disable validation rules
if (setting.All_Opportunity_Disabled__c == false) {
setting.All_Opportunity_Disabled__c = true;
upsert setting;
}
// if the setting field was already true, there's no need to disable it
// but it shouldn't be switched to false by this class once the process has been completed
else {
validationRulesAlreadyDisabled = true;
}
// execute code to manage business process
d = system.today().addDays(6);
for(Opportunity o : [SELECT Id, CloseDate
FROM Opportunity
WHERE CloseDate <= :d
// class only updates open Opportunities
AND Probability > 0 AND Probability < 100])
{
o.CloseDate = System.today().addDays(20);
processedOpps.add(o);
}
if (processedOpps.size() > 0) {
update processedOpps;
}
// reactivate validation rules
if (validationRulesAlreadyDisabled == false) {
setting.All_Opportunity_Disabled__c = false;
upsert setting;
}
}
}
Um sicherzustellen, dass meine Überprüfungsregeln durch die Änderungen an meinen benutzerdefinierten Einstellungen in meiner Klasse deaktiviert werden, habe ich ein Kontrollkästchenfeld Trigger_Validation_Rule__c
(das für Benutzer nicht sichtbar oder zu Seitenlayouts hinzugefügt wurde) und eine Validierungsregel mit diesen Kriterien
AND(
$Setup.Val_Rule_Cntrlr__c.All_Opportunity_Disabled__c = FALSE,
Trigger_Validation_Rule__c = TRUE,
/* allow the above criteria to be met while inserting the Opportunities, without triggering the rule, in the @testSetup portion of the test */
NOT(ISNEW())
)
Ich setze dann das Kontrollkästchen auf " true
wenn Sie meine Opportunities erstellen, sodass die Regelkriterien erfüllt werden, wenn das benutzerdefinierte Einstellungsfeld nicht von meinem Code bearbeitet wird.
@isTest
private class WE_ScheduledCloseDateUpdateTest {
@testSetup
static void dataSetup() {
Profile p = [SELECT Id FROM Profile WHERE Name = 'System Administrator' LIMIT 1];
User u = new User(LastName = 'Test',Alias = 't1',Email = '[email protected]',Username = '[email protected]',ProfileId = p.Id,TimeZoneSidKey = 'America/Denver',LocaleSidKey = 'en_US',EmailEncodingKey = 'UTF-8',LanguageLocaleKey = 'en_US');
insert u;
Val_Rule_Cntrlr__c valRuleCntrlr = new Val_Rule_Cntrlr__c(SetupOwnerId = u.Id,All_Opportunity_Disabled__c = false);
upsert valRuleCntrlr;
List<Opportunity> testOpps = new List<Opportunity>();
// create the Opportunities that will be updated by the class
for(integer i = 0; i < 200; i++) {
testOpps.add(new Opportunity(
Name = 'Test Opp Update' + i,
OwnerId = u.Id,
StageName = 'Prospecting',
CloseDate = date.today().addDays(1),
Amount = 100,
// set checkbox field to true, to trigger validation rules if they've not been deactivated by class
Trigger_Validation_Rule__c = true));
}
// create the Opportunities that won't be updated by the class
for(integer i = 0; i < 200; i++) {
testOpps.add(new Opportunity(
Name = 'Test Opp Skip' + i,
OwnerId = u.Id,
StageName = 'Prospecting',
CloseDate = date.today().addDays(15),
Amount = 100,
Trigger_Validation_Rule__c = true));
}
insert testOpps;
}
// code required to test a scheduled class, see https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_scheduler.htm for more details
public static String CRON_EXP = '0 0 0 15 3 ? 2022';
static testmethod void testCloseDateUpdates() {
// execute scheduled class
Test.startTest();
String jobId = System.schedule('ScheduleApexClassTest',
CRON_EXP,
new Scheduled_OppCloseDateUpdate());
CronTrigger ct = [SELECT Id, CronExpression, TimesTriggered, NextFireTime
FROM CronTrigger
WHERE id = :jobId];
System.assertEquals(CRON_EXP, ct.CronExpression);
System.assertEquals(0, ct.TimesTriggered);
System.assertEquals('2022-03-15 00:00:00', String.valueOf(ct.NextFireTime));
Test.stopTest();
// test results
Integer updateCount = 0;
Integer skipCount = 0;
List <Opportunity> opportunitys = [SELECT Id, Name, CloseDate FROM Opportunity];
for(Opportunity o : opportunitys) {
if (o.Name.contains('Update') &&
updateCount == 0)
{
System.assertEquals(date.today().addDays(20), o.CloseDate, 'Opportunity\'s Close Date should have been updated as it was less than 7 days away');
updateCount = 1;
}
if (o.Name.contains('Skip') &&
skipCount == 0)
{
System.assertEquals(date.today().addDays(15), o.CloseDate, 'Opportunity should not have been updated as it\'s Close Date is more than 7 days away');
skipCount = 1;
}
}
// check that both lists of Opportunities have been tested
System.assertEquals(2, updateCount + skipCount, 'Count should be 2 once all assertions have been executed');
}
// check that the class does not change the custom setting's field to false, if it was true before class was executed
static testmethod void testSettingUpdates() {
User u = [SELECT Id FROM User WHERE UserName = '[email protected]'];
// switch the custom setting field to true before the scheduled job executes
Val_Rule_Cntrlr__c setting;
setting = Val_Rule_Cntrlr__c.getInstance(u.Id);
setting.All_Opportunity_Disabled__c = true;
upsert setting;
System.runAs(u) {
Test.startTest();
String jobId = System.schedule('ScheduleApexClassTest',
CRON_EXP,
new Scheduled_OppCloseDateUpdate());
CronTrigger ct = [SELECT Id, CronExpression, TimesTriggered, NextFireTime
FROM CronTrigger
WHERE id = :jobId];
System.assertEquals(CRON_EXP, ct.CronExpression);
System.assertEquals(0, ct.TimesTriggered);
System.assertEquals('2022-03-15 00:00:00', String.valueOf(ct.NextFireTime));
Test.stopTest();
}
setting = Val_Rule_Cntrlr__c.getInstance(u.Id);
// check that the class did not change the All_Opportunity_Disabled__c field to false
System.assertEquals(true, setting.All_Opportunity_Disabled__c);
}
}