Converteix una llista de SharePoint en una entrada de dades més precisa
Hi ha llistes que comencen senzilles i acaben demanant massa coses. Una petició de material, una incidència tècnica i una alta d’usuari poden conviure a la mateixa llista, però qui crea un registre veu tots els camps alhora. El resultat és conegut: dades omeses, camps emplenats amb guions i missatges posteriors per aclarir què volia dir cada persona.
Una manera eficaç d’evitar-ho és personalitzar el formulari de la llista amb Power Apps perquè adapti els camps al tipus de petició. La llista continua sent la font de dades, amb les seves vistes, permisos i historial; el formulari deixa de ser una graella llarga i es converteix en una petita conversa guiada.
Imaginem una llista de SharePoint anomenada Peticions TI. Té una columna d’opció, Tipus, amb tres valors: Incidència, Material i Alta d’usuari. Per a una incidència necessitem l’impacte i el missatge d’error. Per al material, el model i la data necessària. Per a una alta, el responsable i la data d’incorporació. Mostrar els nou camps en cada cas fa més feixuga l’entrada i empitjora la qualitat de les dades.
Abans de començar, convé revisar tres condicions. La persona que edita el formulari necessita permís d’escriptura a la llista i permís de creació o edició de formularis personalitzats a l’entorn de Power Platform designat. Si l’organització governa els entorns amb cura, l’administració pot separar aquests formularis de l’entorn predeterminat i assignar el rol específic de creador de formularis de SharePoint. Mantén connectors estàndard i dades de Microsoft 365: incorporar connectors premium canvia els requisits de llicència.
A la llista, obre Integrar > Power Apps > Personalitzar formularis. Power Apps genera un formulari connectat a la llista i hi afegeix el control SharePointIntegration, que coordina les accions d’obrir, editar, desar i cancel·lar.
El treball important és conservar aquest cicle de vida i afegir-hi estat explícit:
- Selecciona la targeta de
Tipusi, al control que conté l’opció, configuraOnChangeambSet(varTipus; Self.Selected.Value). - A
SharePointIntegration.OnNew, conservaNewForm(SharePointForm1)i afegeixSet(varTipus; Blank()). Així una petició nova no hereta el tipus de l’anterior. - A
SharePointIntegration.OnEdit, estableix la variable a partir de l’element real:Set(varTipus; LookUp('Peticions TI'; ID = SharePointIntegration.SelectedListItemID; Tipus.Value)). - A la targeta Impacte, defineix
VisibleiRequiredambvarTipus = "Incidència". Repeteix el patró als camps propis de material i d’alta.
Aquest detall sobre la variable sembla menor, però evita un error persistent: l’estat de les col·leccions i variables pot sobreviure mentre la sessió continua oberta. Inicialitzar-lo en els esdeveniments del formulari impedeix que un camp aparegui perquè corresponia al registre anterior.
La decisió té un límit clar. Ocultar una targeta millora l’experiència, però no protegeix dades ni imposa una política. Qualsevol persona amb permisos d’edició sobre la llista pot modificar elements per altres vies, com l’edició en quadrícula. Les regles que afectin compliment, seguretat o integritat crítica han de viure també al model de dades, als permisos o en una automatització validada.
El repte d’avui és modest: tria una llista on un camp només tingui sentit en una situació concreta. Amaga’l amb Visible, fes-lo obligatori amb Required quan correspongui i prova seguidament la creació, l’edició i la visualització d’un element. Aquesta última prova és la que acostuma a revelar els estats que ningú havia pensat.