Change requests og review

Atlas har ét register over jeres landskab. Hvordan en ændring når registeret, afhænger af den tilstand for change management, jeres workspace bruger. En admin vælger tilstanden under Settings › Workspace › Change management.

Vælg en tilstand

Simpel er standard. Den passer til et hold, der vil holde landskabet korrekt uden et formelt godkendelsestrin.

• Med en skriverolle kan du redigere direkte. Brug Undo, hvor handlingen viser den.
• En change request er frivillig. Brug den til at samle flere ændringer, der hører sammen, eller til at planlægge en ændring, der først gælder senere.
• Forfatteren kan selv anvende sin change request.

Review passer til et team, der vil gennemgå ændringer før gennemførelse. Godkendelsen sker på den enkelte change request.

• Ejeren af et element og admins retter det direkte. Andre foreslår en ændring.
• En change request indsendes og godkendes derefter af ejeren af det berørte element eller en admin. Forfatteren kan ikke godkende sin egen, undtagen en admin.
• For en relation, fx et dataobjekt eller en kapabilitet knyttet til en applikation, tæller ejeren af den ene eller den anden ende som ejer. Det samme gælder en integrations middleware og dataobjekter: ejeren af integrationen eller af IT-komponenten eller dataobjektet i den anden ende.
• Godkendelse og gennemførelse er to trin: en dateret ændring venter, til ejeren gennemfører den.

I begge tilstande indsender AI-agenter og connectors forslag, som et menneske vurderer. Hvis du selv har indsendt et forslag via MCP, skal du bruge Atlas eller en anden berettiget reviewer til godkendelsen.

En connector-synkronisering eller en filimport opretter én change request med ét punkt pr. forslag, mærket med sin oprindelse. Godkender du den, kommer forslagene ind i kataloget; afviser du den, afvises de, og næste synkronisering eller import kan foreslå dem igen. Populate viser hvert forslag med et link til dets change request.

Hvornår du bruger en change request

Brug en direkte rettelse til korrektioner: en ejer, en beskrivelse, en klassifikation, en forkert relation.

Brug en change request, når flere ændringer kun giver mening sammen, eller når ændringen skal navngives og drøftes som én ting, fx at udfase en applikation eller skifte dens leverandør. Giv den en titel, der siger hensigten, fx "Udfas Siebel CRM og flyt ordrer til Salesforce", og en beskrivelse, der siger hvorfor.

Åbn Governance › Change requests og vælg New change request. I udkastet tilføjer du punkter: hvert punkt ændrer ét felt på en applikation (navn, beskrivelse, leverandør eller livscyklus) og kan have den dag, hvor det træder i kraft. Forslag fra AI-agenter, connectors og import vises i samme liste som indsendte change requests.

Gennemgå konsekvenserne

På en change request har hver eksisterende applikation, der ændres, et Impact-kort. Gennemgå berørte applikationer og kapabiliteter, ansvarlige, kilder og årsager til usikkerhed før beslutningen. Andre ændrede elementer nævnes særskilt. Unknown betyder, at applikationen ikke har en registreret ansvarlig; Impact is unavailable right now betyder, at Atlas ikke kunne indlæse analysen, ikke at ændringen er uden konsekvenser.

Redigér i en aktiv change request

Åbn Active change request i Atlas-headeren, og vælg en af dine egne change requests med status Draft eller Revision. Valget følger med mellem siderne. Et fact sheet viser et vandmærke og et statusmærke, så du kan se, at understøttede inline-rettelser føjes til denne request; det levende register ændres først, når requesten anvendes eller godkendes. Vælg Editing live i headeren, når du er færdig. Hvis requesten forlader Draft eller Revision, rydder Atlas valget og giver besked. Kun dine egne redigérbare requests vises i vælgeren.

Knappen Edit request på fact sheet åbner requesten. Rettelser, som requesten ikke kan repræsentere, anvendes ikke tavst på det levende register.

Livscyklussen

I Simpel kan forfatteren også anvende et udkast direkte. Siden for en change request viser kun de handlinger, du må udføre i din tilstand og rolle.

Planlagte ændringer

I Inbox viser Waiting for review de nyeste indsendte ændringsanmodninger. Planned changes due viser planlagte punkter med dato i dag eller tidligere, med de ældste først. Kortet markerer dem med Due today (forfalder i dag) eller Overdue (forsinket). Vælg en række for at åbne ændringsanmodningen.

Et punkt kan have den dag, hvor det træder i kraft. Lad datoen stå tom, så anvendes ændringen ved godkendelse. Med en fremtidig dato gemmer godkendelsen beslutningen, men holder punktet ude af det levende register: det er planlagt. Fanen Planned viser alle planlagte punkter efter dato.

Når ændringen faktisk er sket, vælger elementets ejer eller en admin (i Simpel alle med skriverolle) Implement. At gennemføre bekræfter, at ændringen stadig gælder, så den anvendes, også selv om elementet er rettet efter godkendelsen. Et planlagt punkt, hvis dato er passeret, vises som forsinket; Atlas anvender aldrig en plan, fordi en dato er passeret. Change requesten er Implemented, når alle punkter er i drift.

Konflikter

Hvert punkt husker, hvilken version af elementet det blev skrevet mod. Ændrer nogen elementet bagefter, viser change requesten en konflikt, og den kan ikke godkendes, før punktet er fjernet og tilføjet igen.

Gennemg� enkelte punkter

En reviewer, der kan godkende en indsendt request eller gennemf�re en godkendt request, kan afvise et punkt uden at fjerne dets registrering. Afviste punkter forbliver synlige og anvendes aldrig. En konflikt p� et afvist punkt sp�rrer ikke l�ngere godkendelsen. Revieweren kan redigere punktets JSON-indhold; Atlas kontrollerer det f�r lagring og afviser rettelsen, hvis punktet eller det levende element er �ndret, siden revieweren �bnede det. P� en indsendt request venter det rettede indhold p� godkendelse. P� en godkendt request anvendes et �bent punkt straks efter rettelsen.

Accept low-risk godkender en indsendt request, skriver beslutningsposten og anvender update-punkter. Strukturelle oprettelser forbliver �bne til gennemf�relse eller afvisning. Atlas viser, hvor mange punkter der blev anvendt, og hvor mange der er tilbage. De samme regler for tilstand, ejerskab og selvgodkendelse g�lder som ved almindelig godkendelse.

Hvad en godkendelse gemmer

Når en change request godkendes, oprettes en beslutning med titel, beskrivelse, reviewer og alle punkter, og den markeres som selvgodkendt, når forfatteren selv har afgjort den. Anvendte punkter vises i historikken for det element, de ændrede.

Knyt en anmodning til et initiativ

Vælg Related Initiative, når du opretter en anmodning, for at knytte dens konkrete modelændringer til en større indsats. En anmodning, der kan redigeres, kan høre til ét initiativ ad gangen. En kladde kan dokumentere en applikation i initiativets omfang; dokumentationsdækning betyder ikke, at arbejdet er godkendt, gennemført eller realiseret. Se Initiativer.

Skift tilstand

Kun en admin kan skifte. Change requests, der allerede er indsendt, bliver i køen og afgøres som før, og udkast forbliver udkast. Et skift ændrer aldrig historikken.

Sammenlign en request med det levende register

Åbn en change request for at se dens punkter med værdien Before ved siden af hver foreslået ændring. På et applikations-fact sheet, som er knyttet til requesten, viser Compare with live hvert ændret felt som Before, Live og Proposed. Markeringen Conflict betyder, at den levende værdi er ændret, siden punktet blev oprettet; gennemgå den før godkendelse eller anvendelse. Hvis Atlas ikke kan indlæse sammenligningen, siger den det i stedet for at behandle felterne som uændrede. Se Workspace-adgang og invitationer for roller og Ændringer til gennemgang for arbejdet fra en AI-klient.

Brug Governance i Atlas til at vælge mellem en direkte rettelse, en ændringsanmodning og en beslutningspost.