Særlig funktion i implementeringer

Godkendelsesprocesser

• Hvis godkendelsessidefelter indeholder nogen tilpassede felter på standardobjekter, skal manuelt føje disse tilpassede felter til udgående ændringssæt. Indstillingen Vis/tilføj afhængigheder til valg af ændringssætkomponenter indeholder ikke disse felter.
• Hvis godkendelsesprocessen refererer til indlægsskabeloner, der indeholder tilpassede felter, skal du gemme disse indlægsskabeloner igen i den organisation, de stammer fra, før du føjer dem til ændringssættet. Skriv Indlægsskabeloner i feltet Find hurtigt i Opsætning, og vælg derefter Indlægsskabeloner. For hver indlægsskabelon skal du klikke på Rediger og derefter på Gem.
• Ændringssæt inkluderer ikke rækkefølgen af aktive godkendelsesprocesser fra kilden. Nogle gange er det nødvendigt at omarrangere godkendelsesprocesserne i destinationen efter implementeringen.
• Hvis du ændrer Entydigt navn i en godkendelsesproces, der tidligere var inkluderet i et ændringssæt og implementeret i en anden organisation, og du sender godkendelsesprocessen igen via et ændringssæt, oprettes der en ny godkendelsesproces ved implementering i den anden organisation. Den tidligere implementerede godkendelsesproces bliver ikke ændret.

Apex-klasser og Apex-udløsere

Ændringer af Apex-kode, der har Apex-job, der venter eller er i gang, kan ikke implementeres. For at implementere disse ændringer skal du udføre et af disse trin.

• Annuller Apex-job, før du implementerer ændringer til Apex-kode. Rediger tidsplanen for job efter implementeringen.
• Aktiver implementeringer med Apex-job i Salesforce-brugergrænsefladen på siden Implementeringsindstillinger.

Hvis en registrering oprettes i en Apex, markeres testregistreringen ikke som vist. Derfor mislykkes Apex-test med forespørgsler, der filtrerer efter LastViewedDate, under implementering og kan medføre kodedækningsfejl. Hvis du vil markere en registrering som vist i en Apex-test, skal du først bruge FOR VIEW og derefter filtrere efter LastViewedDate.

Dette eksempel på Apex-test bruger FOR VIEW før filtrering efter LastViewedDate.

@isTest
public class AccountViewTest {

    @testSetup
    static void myTestSetup() {
        Account a = new Account();
        a.Name = 'Test Account';
        insert a;
    }

    @isTest
    static void testMethod1() {
        List<Account> aForView = [Select Id, Name from Account LIMIT 1 FOR VIEW];
        List<Account> a = [Select Id, Name from Account where LastViewedDate = TODAY LIMIT 1];
        System.assertEquals(1, a.size());
    }

}

Tilpassede felter

• Hvis du vil ændre datatypen på et tilpasset felt, kan du bruge ændringssæt. Men implementeringen er nogle gange forsinket, når så mange registreringer opdateres. Overvej i stedet at ændre målet gennem brugergrænsefladen.

Tilpassede objekter

• Du kan støde på en fejl, hvis du implementerer et ændringssæt med et tilpasset objekt, der har en overordet-underordnet-relation uden master/detalje-feltet i det samme ændringssæt. Hvis du vil løse denne fejl, skal du inkludere det tilpassede master-/detaljefelt i ændringssættet, selv hvis du ikke har ændret den generelle standard.
• Samtidig indsættelse af et tilpasset objekt, opdatering af feltet sharingModel for et objekt og tilføjelse af en ny ejerbaseret delingsregel understøttes ikke. I stedet kræves der tre separate implementeringer. Implementer først det tilpassede objekt, implementer derefter den opdaterede sharingModel for objektet, og implementer derefter den nye ejerbaserede delingsregel. Du kan opdatere feltet sharingModel og tilføje en kriteriebaseret delingsregel eller en delingsregel for gæstebruger i en implementering.

Forløb

• Hvis du påtænker at implementere et forløb med ændringssæt, skal du tage højde for begrænsninger i migreringsunderstøttelse. Sørg for, at dine forløb kun refererer til felter og komponenter, der er tilgængelige i ændringssæt.
• Du kan kun inkludere en version af forløbet i et ændringssæt.
• Hvis forløbet ikke har nogen aktiv version, når du uploader ændringssættet, bruges den seneste inaktive version.
• Når du får vist de afhængige komponenter for ændringssættet, viser siden Komponentafhængigheder afhængighederne for <i>alle</i> versioner af forløbet. Føj alle afhængige komponenter for den relevante forløbsversion til det udgående ændringssæt.
• Et aktivt forløb i et ændringssæt implementeres på dets destination som inaktivt. Aktiver forløbet manuelt efter implementeringen.
• Implementering eller genimplementering af et forløb ved brug af ændringssæt opretter en version af forløbet i destinationen.
• I produktionsorganisationer kan du aktivere indstillingen til at implementere en ny aktiv version af en proces eller et forløb via ændringssæt eller Metadata API. Indstillingen vises ikke i ikke-produktionsorganisationer (f.eks. scratch, sandbox og udviklerorganisationer), fordi du altid kan implementere en ny aktiv version.

Tilladelser

Se Tilladelsessæt og profilindstillinger i ændringssæt

Sidelayout

En implementering, der indeholder en profil og en registreringstype, men ikke et tildelt sidelayout for den pågældende registreringstype, fjerner den eksisterende layouttildeling fra profilen for den pågældende registreringstype. Medtag altid alle sidelayouts for alle påkrævede registreringstyper i ændringssættet.

Pluklisteværdier

Værdier for et pluklistefelt i et mål, der ikke er inkluderet i ændringssættet, indstilles til inaktive.

Hvis f.eks. målets plukliste indeholder en aktiv værdi på 1, og ændringssættets plukliste ikke indeholder 1 som en værdi, ændres 1 fra aktiv til inaktiv i målet.

Deling

Samtidig opdatering af feltet sharingModel for et objekt og tilføjelse af en ny ejerbaseret delingsregel understøttes ikke. Du kan tilføje en ejerbaseret delingsregel, når den generelle standard er offentlig, og derefter opdatere sharingModel, hvilket resulterer i en enkelt delingsgenberegning. Du kan implementere en kriteriebaseret delingsregel eller en delingsregel for gæstebrugere og ændringer til feltet sharingModel ved brug af ændringssætkomponenter.

Apex-klasser og Apex-udløsere

Ændringer af Apex-kode, der har Apex-job, der venter eller er i gang, kan ikke implementeres. For at implementere disse ændringer skal du udføre et af disse trin.

• Annuller Apex-job, før du implementerer ændringer til Apex-kode. Rediger tidsplanen for job efter implementeringen.
• Aktiver implementeringer med Apex-job i Salesforce-brugergrænsefladen på siden Implementeringsindstillinger.

Hvis en registrering oprettes i en Apex, markeres testregistreringen ikke som vist. Derfor mislykkes Apex-test med forespørgsler, der filtrerer efter LastViewedDate, under implementering og kan medføre kodedækningsfejl. Hvis du vil markere en registrering som vist i en Apex-test, skal du først bruge FOR VIEW og derefter filtrere efter LastViewedDate.

Dette eksempel på Apex-test bruger FOR VIEW før filtrering efter LastViewedDate.

@isTest
public class AccountViewTest {

    @testSetup
    static void myTestSetup() {
        Account a = new Account();
        a.Name = 'Test Account';
        insert a;
    }

    @isTest
    static void testMethod1() {
        List<Account> aForView = [Select Id, Name from Account LIMIT 1 FOR VIEW];
        List<Account> a = [Select Id, Name from Account where LastViewedDate = TODAY LIMIT 1];
        System.assertEquals(1, a.size());
    }

}

Godkendelsesprocesser

• Hvis du vil bruge godkendelsesprocesser på Salesforce Knowledge-artikler med metadata-API, skal artikeltypen implementeres. For artikelversionen (_kav) i godkendelsesprocesser er de understøttede handlingstyper: videnshandling, mailadvarsel, feltopdatering og udgående meddelelse.
• Hvis godkendelsesprocessen refererer til indlægsskabeloner, der indeholder tilpassede felter, skal du gemme disse indlægsskabeloner igen i den organisation, de stammer fra, før du føjer dem til ændringssættet. Skriv Indlægsskabeloner i feltet Find hurtigt i Opsætning, og vælg derefter Indlægsskabeloner. For hver indlægsskabelon skal du klikke på Rediger og derefter på Gem.
• Metadataene indeholder ikke rækkefølgen på aktive godkendelsesprocesser. Det kan være nødvendigt at omarrangere godkendelsesprocesserne i destinationen efter implementeringen.
• Hvis du ændrer Entydigt navn i en godkendelsesproces, der tidligere var inkluderet i et ændringssæt og implementeret i en anden organisation, og du sender godkendelsesprocessen igen via et ændringssæt, oprettes der en ny godkendelsesproces ved implementering i den anden organisation. Den tidligere implementerede godkendelsesproces bliver ikke ændret.

Godkendelsesudbydere

Fra og med november 2022 ændres forbrugerhemmeligheden til en pladsholderværdi, hvis et ændringssæt indeholder en godkendelsesudbyder med en forbrugerhemmelighed defineret. Du skal indsætte forbrugerhemmeligheden manuelt under ændringssætimplementering.

Tilpassede felter

Startende i API version 30.0 er standardfelterne for de redigerbare og læsbare felter i profilfelttilladelser falske, når der implementeres et nyt tilpasset felt. Hvis du vil tilsidesætte standardværdierne, skal du inkludere felttilladelser for det nye felt i dine profiler.

Tilpassede objekter

Samtidig indsættelse af et tilpasset objekt, opdatering af feltet sharingModel for et objekt og tilføjelse af en ny ejerbaseret delingsregel understøttes ikke. I stedet kræves der tre separate implementeringer. Implementer først det tilpassede objekt, implementer derefter den opdaterede sharingModel for objektet, og implementer derefter den nye ejerbaserede delingsregel. Du kan opdatere feltet sharingModel og tilføje en kriteriebaseret delingsregel eller en delingsregel for gæstebruger i en implementering.

Tilsluttet app

• Du kan ikke angive consumerKey i Metadata-API. Det inkluderes i en hentehandling til orienteringsformål. Hvis du forsøger at flytte den tilsluttede app til en anden organisation, skal du fjerne consumerKey fra .zip-filen, før implementering i en organisation. Der genereres en ny nøgle i destinationen.
• Mobilindstillinger for tilsluttede apps understøttes ikke i ændringssæt og skal migreres manuelt.

Grupper

Medlemmer af offentlige grupper migreres ikke, når du implementerer gruppetypen.

Overordnet-detalje-relationer

En metadata-API-implementering, der inkluderer overordnet-detalje-relationer, sletter alle detaljeregistreringer i papirkurven i disse situationer.

• For en implementering med et nyt overordnet-detalje-felt, skal du slette (send til papirkurven) alle detaljeregistreringer, men ikke permanent (soft-slette), før du fortsætter med at implementere master-detalje-feltet. Ellers mislykkes implementeringen. Under implementeringen slettes detaljeregistreringer permanent fra papirkurven og kan ikke gendannes.
• For en implementering, der konverterer en opslagsfeltrelation til en overordnet-detalje-relation, skal detaljeregistreringer referere til en overordnet registrering eller soft-slettes (sendes til papirkurven), hvis implementeringen skal lykkes. Men en vellykket implementering sletter alle detaljeregistreringer i papirkurven permanent.

Sidelayout

En implementering, der indeholder sidelayouttildelinger, erstatter alle eksisterende sidelayouttildelinger i destinationsorganisationen med de tildelinger, der er angivet i .zip-filen. Eksisterende sidelayouts i organisationen forsvinder, hvis de ikke er inkluderet i .zip-filen. Medtag altid alle sidelayouts for alle påkrævede registreringstyper i .zip-filen.

Pluklisteværdier

Værdier for et pluklistefelt i en målorganisation, der ikke er inkluderet i ændringssættet, indstilles til inaktive.

Hvis f.eks. målorganisationen har en plukliste, der indeholder en aktiv værdi på 1, og metadataene ikke indeholder en pluklisteværdi på 1, ændres 1 fra aktiv til inaktiv i målorganisationen.

Profiler

Hvis en pakke indeholder en profil med et navn, der ikke findes i målet, oprettes der en ny profil med dette navn. Hvis den implementerede profil ikke angiver nogen tilladelser eller indstillinger, består den resulterende profil af alle tilladelserne og indstillingerne i standardprofilen.

Tilpassede felter på ContentVersion-objektet er tilgængelige for alle profilbrugere. Når du eksporterer profilmetadata, vises alle tilpassede felter.

Deling

• Med API version 29.0 kan du ikke ændre sharingModel på et objekt ved brug af metadata-API. Rediger målet manuelt gennem brugergrænsefladen.
• Startende med API version 30.0 kan du ændre sharingModel for et objekt for interne brugere ved brug af Metadata-API og brugergrænsefladen.
• Samtidig opdatering af feltet sharingModel for et objekt og tilføjelse af en ny ejerbaseret delingsregel understøttes ikke i Metadata-API. Du kan tilføje en ejerbaseret delingsregel, når den generelle standard er offentlig, og derefter opdatere sharingModel, hvilket ville resultere i en enkelt delingsgenberegning. Du kan implementere en kriteriebaseret delingsregel eller en delingsregel for gæstebrugere og ændringer til feltet sharingModel ved brug af Metadata-API.

Arbejdsflow

Testtilstand for forløbsudløsere understøttes ikke i metadata-API. Hvis du ønsker, at en forløbsudløser skal køre den seneste forløbsversion, når en administrator forårsager, at arbejdsflowreglen køres, skal du aktivere testtilstand via brugergrænsefladen efter implementering.