Moritz

Hey @Mats Matern, leider gibt es hierfür keinen Webhook, der genutzt werden könnte um die Information zugestellt zu kriegen ("Push") – so wie das für neue Datensätze möglich ist. Was du aber machen könntest, ist deine smap in einem regelmäßigen, sinnvollen Intervall (z.B. alle 30 Minuten) auf neue Versionen zu prüfen ("Pull").
Z.B. gibt es in der internen API (siehe FAQ: Wie wähle ich in der Swagger API-Dokumentation die interne API aus?) den Endpunkt zum Abrufen aller Informationen zu einer smap, u.a. auch die letzte Versionsnummer
GET /Smaps/{smapId}

 
Oder auch den Endpunkt zum Abrufen aller Versionen
GET /Smaps/{smapId}/Versions

 
Was du nun noch selber realisieren müsstest, wäre eine Art Zwischenspeicher für die letzte Versionsnummer. So dass du in jedem Abruf prüfst, ob du neue Versionsnummer der zuletzt gespeicherten entspricht. Ist das nicht der Fall, liegt eine neue Version vor und du kannst deine Tätigkeiten wie gewünscht weiterführen.
Hierfür gibt es (zumindest nach meinem Kenntnisstand) keinen einfachen Zwischenspeicher. Hierfür könntest du eine separate Datenquelle einbinden, z.B. Dataverse; aber man könnte auch eine Textdatei in SharePoint/OneDrive ablegen (das wäre wahrscheinlich mein Ansatz, weil einfach umzusetzen) oder eine MySQL-Datenbank anzapfen.
Die Schritte in Power Automate würden dann in etwa wie folgt aussehen:
Auslesen der Textdatei aus OneDrive (da steht nur eine Information drin, nämlich die letzte Versionsnummer, z.B. "1.0" per OneDrive-Datei-Lesen-Action. Abruf der Versionsnummer wie oben beschrieben per /Smaps/{smapId} per HTTP-Action. Vergleich der Versionsnummern. Wenn Versionsnummern ungleich, dann Prozess weiterführen, andernfalls abbrechen (weil keine neue Version). Vergleich der Versionsnummer aus dem 

Hallo @Mats Matern, was hast du denn vor mit dem PDF?
Ansonsten bist du beim falschen Request! In deinem Screenshot rufst alle Datensätze einer smap oder einer Version ab. Da erhält man immer ein ZIP-File, welches die Einzel-PDFs beinhaltet.
Der API-Endpunkt, den du suchst, ist der hier (beachte die recordId).
GET /Smaps/{smapId}/Versions/{version}/Data/{recordId}.{format}

@Connor Jessen au ja, das sind valide Punkte. Hier sehe ich zwei weitere Möglichkeiten, wie man das Problem mit den aktuellen Möglichkeiten umschiffen könnte.
Variante 1: Labels mehrsprachig vorhalten
Hierzu fügst du einfach mehrere Sprachen in den Beschreibungstext ein. Somit hast du nur eine smap und jeden Baustein auch nur ein einziges Mal.

 
Variante 2: Sprachenspezifische Erklärungstexte nach vorheriger Auswahl
Du könntest auch Erklärungstexte in den jeweiligen Sprachen hinterlegen und den User zunächst seine gewünschte Sprache auswählen lassen. Dann hast du auch wieder nur eine smap und jeden Baustein auch nur einmal.


Hier habe ich sogar die mehrsprachigen Labels aus der Variante #1 mit übernommen. Aber du solltest das Konstrukt verstehen: Ein User wählt die Sprache zu Beginn der smap aus und alle Erklärungen werden dann sprachenspezifisch eingeblendet.

Achso P.S. Interessant wird hier übrigens, falls mal jemand aus dem Backgewerbe anwesend ist, die erforderliche Anpassung hierfür:
 
Und außerdem könnte man noch eine Abfrage in der smap realisieren, die noch die Bedingung nach (4) prüft:
 
Also wenn ich das korrekt deute so etwas wie ein "finales" Ergebnisfeld mit der Formel:
IF(LESSTHAN({ResultNumber_3}, 2), 0, {ResultNumber_3})  
Disclaimer: Ich bin kein Jurist, diese Beitrag stellt keine juristische Beratung dar. Zu Risiken und Nebenwirkungen fragen Sie Ihren Anwalt oder Justiziar 😉

Dir könnte eine Formel wie diese hier helfen:
IF(EQUALS({DataRecordSelect[Monteur]}, "-Monteur neu-"), {Texteingabe_Name}, {DataRecordSelect[Monteur]}) Kurze Erklärung, im ersten Schritt wird geprüft, ob der ausgewählte Monteur ein neuer Monteur sein soll. Wenn dies der Fall ist, dann soll er den manuell eingegebenen Namen verwenden. Andernfalls den Namen aus dem DSAB.
Guvk mal ob das klappt. Die Baustein-IDs musst du natürlich für deine Zwecke anpassen.

Hey @FrederikWo, nein das geht aktiell leider (noch) nicht. Jedenfalls nicht als Standardfunktion. Siehe https://faq.smapone.com/kb/guide/de/kann-ich-zwei-verschiedene-berichte-zu-einer-smap-hinterlegen-UQXsKGDn6X/Steps/843486.
Man kann aber mit der API tricksen: du könntest eine zweite smap mit einer anderen Berichtsvorlage (aber ansonsten komplett identischen Struktur) erstellen. Immer, wenn ein Nutzer die smap abschickt, wird der Datensatz per Webhook an einen Automatismus gegeben, dieser erzeugt mit den Daten eine Aufgabe für die zweite smap. Hier muss der User nur noch die Aufgabe öffnen und den Datensatz abschicken, dann liegt das zweite PDF vor.

In einem anderen Beitrag hier im Forum hatte @Wolfgang Kotzbeck danach gefragt, wie man die letzte Eingabe von Werten wieder in der smap merken/speichern kann. Dort wurden bereits mögliche Varianten diskutiert; ich hatte eine Variante skizziert, wie man den letzten Wert über die Aufgabenfunktion "transportieren" kann.
 
Eine weitere Möglichkeit wäre, dass man sich hierzu des Datensatzauswahlbausteins (kurz DSAB, siehe FAQ: Wie funktioniert der Datensatzauswahlbaustein?) bedient. Das Szenario ähnelt dem obigen – nach jeder Fahrt wird ein Kilometerstand erfasst, dieser soll für das Fahrzeug gespeichert werden; zusätzlich noch der letzte Fahrer – und sieht in etwa wie folgt aus:

Wir tragen den neuen Kilometerstand in der smap ein, außerdem wird der Fahrername automatisch über die angemeldete User-Emailadresse ({user:email}) ermittelt. Und zwar über die mehr als elegante Lösung von @Mr Smap😉 Ein Webhook (muss initial einmal über die API eingerichtet werden, siehe FAQ) sendet den Datensatz an einen Automatismus-Dienst (z.B. Power Automate). Der Automatismus nimmt den Webhook entgegen, extrahiert aus den übermittelten Daten den neuen Kilometerstand und Fahrer, beschafft die alten DSAB-Daten, filtert hieraus den betroffenen Eintrag (anhand des Kennzeichens), modifiziert in diesem Eintrag den KM-Stand und letzten Fahrer, baut hieraus und mit den anderen DSAB-Daten wieder einen neuen Datenstand und schickt diesen an die smapOne-API zurück (siehe FAQ) so dass die aktualisierten Daten dort wieder vorliegen. Im Video ist das ganze sehr viel detaillierter aufgeführt und kann einfach nachgebaut werden. Auf Nachfrage stelle ich auch gerne den Flow als ZIP-Datei zum Herunterladen, Importieren und Nachvollzoehen bereit.
 
Fragen zum Video, zum Automatismus, zur smap und zu meinen Ausführungen hier gerne einfach direkt hier reinschreiben. Alternativ könnt ihr auch gerne direkt einen Kommentar auf YouTube unter dem Video hinterlassen. Auf diesem YouTube-Kanal ("smappetizer") wird es zukünftig weitere Deep Dive Tutorials geben, es lohnt sich also, den Kanal zu abonnieren 😉

So, das Video ist fertig. Wohl bekomm's!
 

Hey @Steffen Haußmann, einmal abgesendete Datensätze sind unveränderlich.
Den von dir aufgezeigten Weg (alten zu bearbeitenden Datensatz laden und als Aufgabe wieder zurückspielen; ggf. alten Datensatz löschen) ist genau der, den ich auch empfehlen würde (und in dieser Form auch schon für einige Kunden umgesetzt).
Man könnte noch über eine Variante (ohne REST API) nachdenken, dass Datensätze einfach nicht abgesendet, sondern grundsätzlich als Aufgabe weitergeleitet werden. Der Aufgabenempfänger führt dann die Qualitätskontrolle durch (wenn das Foto dann z.B. verwackelt ist, kann das Foto herausgelöscht und als Aufgabe wieder zurückgegeben werden) und sendet den Datensatz final ab.

Es ist schon eine ganze Weile her, aber dennoch nicht weniger aktuell: Im Juni 2021 hatte ich ein kurzes Video produziert, in dem ich die wesentlichen Möglichkeiten der Integration von smapOne in die eigene Unternehmensinfrastruktur aufzeige.
Es geht nicht allzusehr in die Tiefe (derartige Tiefgangvideos werden euch hier im Laufe des kommenden Jahres erwarten!), aber gibt schonmal einen kurzen Einblick, was denn so möglich ist, wenn man Daten in eine smap hinein oder aus ihr herausbekommen möchte.
Nutzt diesen Thread im weiteren auch gerne für Fragen hinsichtlich der Integration und Automatisierung.

Ich wurde einmal gefragt, ob bzw. wie es möglich sei, Inhalte aus QR-Codes in verschiedene Felder aufzutrennen. Zugegeben, das ist nicht trivial. Aber mit Hilfe unserer Formeln und Ergebnisbausteinen können wir uns das Ergebnis zusammenschustern.
Beispielsweise beinhaltet dieser QR-Code...

... den folgenden Textinhalt:
Moritz|Hesse|moritz.hesse@smapone.com|https://forum.community.smapone.com/profile/58-moritz-hesse/ Also zunächst einmal meinen Vornamen, Nachnamen, Emailadresse und Link zu meinem Profil hier in der Community. Alle jeweils getrennt durch ein "|" ("Pipe"). Diese vier Einzelwerte kann ich mir nun auf vier eigenen Ergebnis- oder auch Eingabefelder aufsplitten, so dass die Daten nicht nur "diskret" im QR-Code hinterlegt, sondern auch für uns Menschen lesbar und weiterverarbeitbar sind.
Wenn ich das ganze nun in einer smap abbilden möchte, dann muss ich mit einigen Zwischenschritten arbeiten. Der Einfachkeit halber lege ich diese Zwischenschritte im Folgenden in eigene Ergebnisfelder. Da diese Zwischenwerte in einem echten Datensatz allerdings nicht benötigt werden, kann man die Formeln auch enstprechend verdichtet ohne Zwischenergebnisfelder aufbauen (bei Interesse einfach mal bei mir nachfragen, wie das geht).
Sodenn, los geht's: Klar, die smap benötigt natürlich zunächst einmal einen Codescanner-Baustein. Als nächstes erstellen wir einen Textergebnisbaustein, in den wir die folgende Formel einfügen:
TEXTPOS({CodeScanner}, "|") Diesen Baustein nenne ich {Pipe_pos_1}, da er die Position des ersten Pipes in dem Text zurückgibt.


Dieses Ergebnis, also diese Zahl kann ich nun verwenden, um im nächsten Schritt aus dem Codescanner-Inhalt meinen Vornamen zu extrahieren. Denn wir wissen: Alles bis zum ersten Pipe ist der Vorname. Also nehmen wir die Formel...
SUBTEXT({CodeScanner}, 0, SUB({Pipe_pos_1}, 1))
... und erhalten damit bereits sauber extrahiert den Vornamen. Da wir das Pipe-Trennzeichen selber nicht mitnehmen wollen, subtrahiere ich von der Positionsnummer noch eine 1.

Um die weiteren Felder zu extrahieren, muss ich zunächst den "Rest-Text" ermitteln. Das mache ich, indem ich einfach den Text vom ersten Pipe bis zum Ende des Codescanners extrahiere:
SUBTEXT({CodeScanner}, ADD({Pipe_pos_1}, 1), LENGTH({CodeScanner}))

Und diesen Rest werte ich nun nach dem gleichen Schema aus, wie ich das schon initial mit dem Vornamen gemacht habe: Ich ermittle die Position des zweiten Pipes in dem vorhandenen Rest-Text.
TEXTPOS({Rest_1}, "|")

Und mit Hilfe dieser Position kann ich nun auch den Nachnamen extrahieren:
SUBTEXT({Rest_1}, 0, SUB({Pipe_pos_2}, 1))
Die Emailadresse wird wieder nach dem gleichen Verfahren extrahiert, nun einfach ein Pipe "später":
Dazu ermittle ich den Rest ohne Vor- und Nachname in ein Textfeld...
SUBTEXT({Rest_1}, ADD({Pipe_pos_2}, 1), LENGTH({Rest_1})) ... dann ermittle ich wieder die Position des nächsten (und letzten) Pipes in ein Zahlenergebnisfeld...
TEXTPOS({Rest_2}, "|") ... und kriege die Emailadresse als Subtext zwischen Anfang und Pipe:
SUBTEXT({Rest_2}, 0, SUB({Pipe_pos_3}, 1)) Um am Ende die URL zu meinem Community-Profil zu extrahieren, brauchen wir nur noch den Rest, reduziert um das letzte noch vorhandene Pipe. Die Formel ist also die gleiche wie oben, um den jeweils noch übrigen Rest zu ermitteln:
SUBTEXT({Rest_2}, ADD({Pipe_pos_3}, 1), LENGTH({Rest_2}))
Das Resultat der ganzen Initiative sollte dann in etwa so aussehen:

Beziehungsweise, wenn ihr (sinnvollerweise) die Zwischenschritte ausblendet ("Den Baustein in der App nicht anzeigen") oder (noch besser) direkt ohne Zwischenschritte arbeitet, dann sollte euer Ergebnis so oder so ähnlich aussehen:

Na, bis hierhin durchgehalten? Gratulation, du bist ein echter smappie! 😉 Wenn du dir diese Lösung gerne einmal in einer fertigen smap in deinem eigenen Designer ansehen möchtest, schick mir eine kurze Nachricht, dann lasse ich dir diese Beispielsmap als smap-Kopie zukommen.

Ja, manchmal möchte man eine Checkbox zum Pflichtfeld machen. Sowas wie "Ja, ich habe die Bedingungen gelesen und bin einverstanden". Weiter soll es nur gehen, wenn die Checkbox angehakt wurde. An anderer Stelle hier im Forum gibt es dafür einen sehr interessanten Workaround von @Jan Pietsch.
Nun ist es mit dem Checkbox-Baustein so, dass man ihn zwar standardmäßig aktivieren (= anhaken) kann. Man kann ihn aber nicht zum Pflichtfeld machen.

Die Lösung ist ein Einfachauswahlbaustein mit nur einer Auswahlmöglichkeit ("ja", "okay" o.ä.) kombiniert mit der Pflichtfeld-Einstellung:

Somit kann ich in der smap erzwingen, dass die "Checkbox" angehakt ist, um weiterzumachen bzw. um den Datensatz abzusenden.

Zunächst vorab: nur mit smapOne-Bordmitteln alleine wird es nicht funktionieren, dass auch das hochgeladene PDF-Dokument mit in der Email versendet wird. Eine solche Lösung liesse sich aber individuell entwickeln (mit irgendeinem externen Dienst, den man hierfür einsetzt, z.B. PowerAutomate, Zapier; es könnte aber auch ein lokal betriebenes Software-Script sein).
Wenn Sie nun einem Ihrer User eine smap bereitstellen möchten, in der bereits ein für den jeweiligen Vorgang individuelles PDF-Dokument enthalten ist, sehe ich hierfür zwei Wege, beide funktionieren über den Weg einer smap-Aufgabe, die einem User zugestellt wird (mehr zu Aufgaben siehe unsere FAQ).
(automatisiert) Ein Script/Dienst o.ä. beschafft die jeweils aktuelle PDF-Datei und erzeugt eine Aufgabe für die smap, in die diese PDF-Datei eingefügt wird. Der User erhält nun die Aufgabe, in der das PDF enthalten ist. (manuell) Ein Disponent/smap-User startet einen neuen Entwurf, läd dort die PDF hinein und weist diesen Datensatz dann als Aufgabe der Person zu, die mit dieser PDF arbeiten möchte.

@Wolfgang Kotzbeck ich habe mir den Prozess nochmal durch den Kopf gehen lassen. Variante 4 (Kilometerstand neu als Vorbelegung in das Zahleneingabefeld) ist die schwierigste Variante von allen (weil die Definition über die API anzupassen tatsächlich Köpfe zum Rauchen bringen kann).
Ich sehe noch eine abgespeckte Variante, die vergleichsweise einfach umzusetzen ist: Und zwar können wir den neuen Kilometerstand nach Absenden eines Datensatzes abgreifen und als neuen Ausgangswert in eine Aufgabe zu schreiben. Diese Variante setzt allerdings voraus (zumindest dieses konkrete Szenario), dass die smap immer nur von einem User verwendet wird (damit immer klar ist, wem die Aufgabe zuzuweisen ist) und nicht mehrere unterschiedliche User auf die smap zugreifen.
Das gesamte Szenario sieht in etwa wie folgt aus:

Wir tragen den neuen Kilometerstand in der smap ein. Ein (zuvor einmalig in der API eingerichteter) Webhook sendet den Datensatz an einen Automatismus-Dienst (z.B. PowerAutomate). Der Automatismus extrahiert aus den übermittelten Daten den neuen Kilometerstand... ... und erzeugt eine neue Aufgabe mit diesem neuen Kilometerstand als neuem Ausgangswert für die nächste Fahrt.  
Aber die Schritte im Einzelnen und was dafür zu tun ist:

Um einen Datensatz absenden zu können, muss natürlich die smap dafür existieren und ein entsprechendes Zahleneingabefeld beinhalten. Für unseren Szenario nenne ich diesen Baustein {Kilometer_neu}.

 

Für den nächsten Schritt ist es erforderlich, dass wir über die REST-API einen Webhook einrichten. Ein Webhook informiert ein externes HTTPS-Ziel darüber, dass ein neuer Datensatz eingegangen ist und sendet diesen (sofern entsprechend konfiguriert) direkt mit an das Ziel.
➡️ FAQ: Welche Funktion hat ein Webhook und wie verwalte ich sie?
Damit der Webhook die Daten sinnvoll an das HTTPS-Ziel übergeben kann, muss dieses natürlich existieren. Also muss hierzu entweder selbstständig ein HTTP-Server betrieben werden oder alternativ Cloud-Systeme wie PowerAutomate oder Zapier eingesetzt werden. Für mein Beispiel habe ich einen PowerAutomate "Flow" entwickelt (so heißen Algorithmen, mit denen bei PowerAutomate automatisiert/integriert wird).

Dieser Flow führt folgende Schritte durch

Entgegennehmen des Webhooks (in dieser Action wird auch eine URL erzeugt, die dann als HTTPS-Ziel verwendet werden kann) Hinterlegen der smapID. Hinterlegen des API-Tokens (siehe ➡️ FAQ REST-API-Token verwalten). Abrufen der letzten/aktuellen smap-Version (um später die Aufgabe für die richtige Version zu verteilen). Extrahieren der smapVersion aus vorherigem Abruf. Extrahieren des neuen Kilometerstands aus den Daten des per Webhook erhaltenen Datensatzes. Eintragen des neuen Kilometerstands (in das Feld "Kilometerstand alt") und Abenden/Zustellen als Aufgabe. ➡️ FAQ: Die Aufgabenfunktion einer smap: Wie ermögliche, erstelle und verwalte ich Aufgaben?
Die Schritte im Einzelnen zu erklären, geht über diesen Thread hinaus. Ich werde in Zukunft in (Video-)Tutorials zeigen, wie man die o.g. Varianten oder dieses Szenario hier mit Hilfe von PowerAutomate umsetzen kann.
Ich stelle den Flow aber gerne als Export zum Download und Import in den eigenen PowerAutomate-Account zur Verfügung: TutorialKilometerstand_PowerAutomate.zip

Der PowerAutomate-Flow hat nun via die smapOne-API eine Aufgabe erzeugt, die dem ursprünglichen Absender eine Aufgabe erzeugt, in der der neue Kilometerstand als Wert im neuen Kilometerstand-Feld eingetragen ist.
 
So sieht das Ganze dann im Einsatz aus:

... PowerAutomate rödel, tut und macht; beschafft sich den alten Wert und trägt ihn in das Feld für den neuen KM-Stand ein...

... und siehe da, wir haben eine Aufgabe, in der der neue Kilometerstand auf Basis des alten Werts eingetragen wurde:

... und in der smap selber ist der Wert natürlich auch schon eingetragen (kann aber auch korrigiert werden):

 
Tadaaaa: Easy as that... 😉