Changelog
Was ist neu?
Jede Verbesserung an der Plattform, wie sie geliefert wird.
· MCPGatewayService
Identity_request_confirmation; eine Anfrage, die das Mitglied in Kamo bestätigt hat, ist seine Bestellung
Besitzer 2026-10-26: Direkte Bestellungen müssen authentifiziert werden. Jemand, der nur behauptet, ein Besitzer zu sein Teamkollege (Telefon, Text, unbewiesene E-Mail, Website-Chat, Meeting) wird gefragt, durch kamoai-service, um in ihrer angemeldeten Kamo App zu bestätigen; dem SI wird in klaren Worten gesagt, was zu tun ist Nach der Bestätigung beantwortet RequestVerifier die Reihenfolge der Ausführung und die Anforderung von diesem Bestätigung (auth:<id>): das Mitglied hat dafür gebürgt, also zählt der Taint des Channels nicht und SI_AUTH_REQUEST erreicht niemals eine SI, da es sich um ein eigenes Ablaufdatum handelt.
· SecurityService
Wenden Sie eine generierte Persönlichkeit auf die eigene Charta eines SI an, um das herum, was die Leute festlegen
Sprachrealismus VR2, Eigentümerentscheidung D2: Jeder SI bekommt einen einzigartigen, job-fit Persönlichkeit, generiert aus eigener Arbeit. kamoai-service entwirft sie; diese Der interne Endpunkt (KamoAI secret) wendet seine PERSONALITY- und VOICE-Elemente auf die So wie ein Save es tut: bestätigt durch die eigenen Regeln des Charters, auf Autorität abgelehnt Sprache, geschrieben von MemberCharterWriter, gekennzeichnet AI_DRAFT, angekündigt, so dass die Die Laufzeit liest die Charta erneut und wird als AI_CONFIGURATION_APPLIED geprüft. Gegenstände, die eine Person eingestellt hat, werden immer beibehalten; eine frühere Generation wird ersetzt.
· kamo-internal
Die Meeting-Einladungsoption wird eingeengt, standardmäßig kein zusätzliches Limit
Besitzerentscheidung 2026-10-26: Der eigene Zugang der SI entscheidet, wer sie einladen kann (jeder im Team, wenn es Meetings, sonst nur die Vorgesetzten); diese Option, die zuerst als Standard angezeigt wird, schränkt das nur ein.
· MediaService
Die eigenen Rechte der SI entscheiden, wer sie zu einer Sitzung einladen darf
Besitzerentscheidung 2026-10-26, in der gemeinsamen Prüfung (MeetSiInvitePolicy) hinter der In-Meeting-Einladung, M1, Meeting Erstellen und der M3-Picker: - die Vorgesetzten der SI (Reporting Line, Organisator) können sie immer einladen: ihr direkter Befehl verleiht ihr ihre Politik; - jeder andere in seiner Organisation kann, wenn die SI's OWN angewendeten Rechte VIEW_MEETINGS enthalten (das Recht, meetings_join und M1 join benötigt), und es nimmt mit seinem eigenen Zugriff teil; seine optionale meeting_invite_policy kann es eingrenzen; - andernfalls 403 SI_NEEDS_SUPERVISOR (oder NOT_ALLOWED_TO_INVITE_THIS_SI für die optionale Einschränkung). Die Raumliste gibt jetzt auch die SIs zurück, die diese Person nicht einladen kann, als LOCKED mit lockedReason, so dass das Panel Rechte lesen auf ix_mra_member_right; unlesbar = nur für Supervisoren.
· AIService
Die Option Meetingeinladung ist eine optionale Einschränkung, standardmäßig keine
Eigentümerentscheidung 2026-10-26: Die eigenen Rechte der SI entscheiden, wer sie einladen kann (jedes Teammitglied, wenn sie Meetings beinhalten, Ansonsten nur seine Vorgesetzten). **************** ist jetzt standardmäßig auf ORGANIZATION (keine Einschränkung); DDL **************** angewendet (Standard + vier Zeilen, die nur den alten Standard enthalten).
· kamo-shared-library
Die eigenen Rechte der SI entscheiden, wer sie einladen kann; meeting_invite_policy ist nur eine optionale Einschränkung
Besitzerentscheidung 2026-10-26: Eine SI, deren eigene Sicherheitsrichtlinie Meetings erlaubt, kann von jedem Teammitglied eingeladen werden; Eine Organisation, deren Politik nicht nur von ihren Vorgesetzten bestimmt wird (ihre direkte Ordnung verleiht ihr ihre Politik) Als optionale zusätzliche Einschränkung, deren Standardeinstellung, ORGANIZATION, nichts einschränkt (war SUPERVISORS).
· kamo-shared-library
Jeder SI spricht durch seine Persönlichkeit, und die Tabellen für Hintergrundgeräusche, Sprachzustimmung und Anruferphrasenspeicher
PhoneStyle kompiliert die Merkmale eines SI in gesprochene Telefonregeln (Kontraktionen und Adresse Formen, Wärme, Humor, Energie, Absicherung, Empathie, Neugier, Register, Regionalformulierung) plus die Zahlen, die die Voice-Pipeline anwendet: eine Füllkappe pro Ruf (D3, bis zum A/B aus), die Lücke zwischen den Hörtönen (D4), Lachen Der Emotionsumfang (D6), der Ruheton und die End-of-Turn-Patience. Ein SI Dieses Programm ohne Persönlichkeit spricht noch mit den Registry-Standards (D2). AiAmbienceSetting (D7), AiVoiceCloneConsent (D12) und KamoInitializer kann die neuen Tabellen von kamoai-service neu erstellen.
· MediaService
SIs spielen Texas Hold'em mit Mitgliedern, und jeder Cheddar eines Mitglieds funktioniert wieder
SITP TPGAMES (Eigentümer 2026-10-26). Brieftasche aus Cheddar: - Die einzige Tür des Wallets (universe-gateway -> universe-persistence) hat Es gibt keine Endpunkte, da das KamoUniverse Spiel am 2026-09-28 geparkt wurde, also jedes Hold'em-Buy-in ist seitdem fehlgeschlagen ('die Cheddar-Wallet antwortet nicht'), CheddarLedger schreibt die gleichen drei Tabellen in die Datenbank, um die gleichen Informationen zu erhalten kamouniverse-Datenbank direkt (gleicher Cluster, eigener DB-Benutzer dieses Dienstes), Regeln des Persistenzdienstes: eine Transaktion pro Bewegung, eindeutig Idempotenzschlüssel (Replay = angewendet false), signierte Hauptbuchzeile; eine Belastung ist eine Bedingte Aktualisierung, damit zwei Buy-ins nicht überzogen werden können. CheddarWalletClient jetzt Jeder benutzt es. - Die einmalige Anmeldegebühr (1.000.000, Schlüssel signup_grant:<id>), die nur Die größte geparkte 3D-Welt, die jemals erstellt wurde, wird beim ersten Mal erstellt, wenn ein Mitglieds-Wallet Berührt durch eine Spiele-App, die sie haben - Person oder SI das gleiche. CheddarSiGrants öffnet die Geldbörse jedes nicht pensionierten SIs im Voraus (stündlich, singleton, paging durch die SI-Roster-Mitglieder-IDs; nichts anderes berührt). Cheddar hat keinen Kaufpfad, so dass kein SI ihn jemals mit Geld kauft. Texas Hold'em SI: - HoldemSiBrain: Monte Carlo Equity über HandEvaluator gegen die Live-Gegner, Pot Odds, Stil CAUTIOUS/BALANCED/BOLD und Skill CASUAL/CLUB/SHARP, 300 ms Seine einzige Eingabe ist die HoldemTableView des SI pro Empfänger: eigene zwei Karten und öffentliche Informationen, niemals andere Karten oder das Deck. - HoldemSiPlayer: ereignisgesteuert (HoldemTurnEvent nach jedem veröffentlichten Frame, ~1.4-2.3 s Pause innerhalb der 30 s Uhr). Sitzt, wenn eine Person es eingeladen hat und Sitzt, handelt über HoldemGameService.act mit expectedSeq, Rebuys bei Höchstens 3 Mal am Tag pro Tisch, sitzt mit einer aussitzenden Person aus und geht Wenn keine Person übrig ist: SIs spielen niemals untereinander. Redis Anspruch pro Tabelle; Stil/Fähigkeit pro SI pro Tabelle in Redis. - HoldemSiEligibility jeden Schritt: Hold'em-App, PLAY_HOLDEM (SI's, oder die Einladende/sitzende Person: Keine Insubordination), Laufzeit nicht pausiert. - POST /tables/{id}/si-play (style, skill), nur der aufrufende SI. - ChessFaces liest den Theme-Host außerhalb der Transaktion (Ratchet), gecached. Tests: CheddarLedgerTest 4 (H2), HoldemSiBrainTest 5, HoldemSiFairnessTest 3 (Die Ansicht des SI enthält keine Karten anderer Spieler und kein Deck; verdeckte Karten Der Spieler kann die Entscheidung nicht ändern; er hat keine Tür zu den Rohhandreihen), HoldemSiPlayerTest 7; Spiele Suiten 240 grün.
· MCPGatewayService
Mail_send nimmt eine Klartext-Version des HTML-Textkörpers und eine Textdatei, die vom Aufrufer geschrieben wurde (TPRECAPS)
Die Zusammenfassung des SI-Meetings enthält jetzt das vollständige Transkript des Meetings; nach dem Körperlimit wird es als .txt-Anhang gesendet. textBody (mit bodyFormat HTML) wird zum mehrteiligen/alternativen Textteil; textAttachmentName + textAttachment werden Ein Anhangsteil (Name auf sichere Zeichen beschränkt, .txt) Der angehängte Text wird mit dem Textkörper zur Offenlegung geplant. Goldene Werkzeuglisten regeneriert (nur mail_send).
· EmailService
Absenderdaten einer Nachricht für SI-Identitätsprüfungen; SI_AUTH_REQUEST gehört keiner App
Die Provenienzantwort sagt nun auch, was die Nachricht selbst über ihren Absender behauptet: Von, Reply-To, der Server, der es an unseren übergeben hat, und die SPF/DKIM/DMARC-Ergebnisse, die in seinem SI_AUTH_REQUEST ist nicht angegeben: jeder kann von einem Benutzer nach einer Authentifizierung gefragt werden Eine SI, um zu bestätigen, dass eine Anfrage wirklich von ihnen stammt.
· kamo-shared-library
SI_AUTH_REQUEST-Benachrichtigungsart und die SI-Authentifizierungs-Log-Entitäten
Besitzer 2026-10-26: Direkte Befehle, die eine SI über einen Kanal erreichen, der niemanden identifiziert Alle Änderungen müssen zuerst vom Mitglied in Kamo bestätigt werden. Appends **************** (gehört zu no app), deklariert si_auth_requests / si_auth_request_events (von Hand angewendete DDL in kamoai-service **************** und der media_session_guid Index von support_ticket.
· kamo-internal
Wählen Sie aus, wer einen SI zu Besprechungen einladen kann, in den Anrufoptionen
Kamo Meet "Eine SI einladen" (Besitzerbefehl 2026-10-26): Nur die Personen, die sie betreuen (Standard) / Ihre Betreuer und Teammitglieder / Jeder in Ihrer Organisation, mit einer einfachen Erklärung für jeden. Gespeichert durch AIService; MediaService setzt es durch.
· MediaService
Laden Sie einen SI aus dem Meeting ein; wer einen SI einladen kann, ist die Wahl des SI
Kamo Meet "Eine SI einladen" (Besitzerbefehl 2026-10-26): - GET **************** für eine angemeldete Person IN der Besprechung (Ersteller, aufgezeichnete Teilnehmer, (oder erhalten den Token dieses Raumes vom Meeting-Sidecar aus ihrer eigenen Sitzung: MEETPRES-Zeichen), die aktiven SIs der Organisation, die sie Sie können einladen, gruppiert SUPERVISED / VERFÜGBAR, mit Foto (Foto -> Avatar), Jobtitel und Verfügbarkeit (verfügbar, Keine SI in oder auf dem Weg zu dieser Besprechung (z. B. nicht online, aber kann teilnehmen, in einem anderen Anruf, angehalten, nicht verfügbar) (Live-Teilnehmer, Einladung zum automatischen Beitreten, Live-ai_call hinein); einer, der übrig geblieben ist, wird erneut aufgelistet. - POST .../invitable-sis/{memberId}: bringt es jetzt über M1s Ein-Instanz-Pfad (teilnehmender Upsert, exklusiver Dial Claim; kamoai-services einzigartiger Live-Call-Index dahinter): gleichzeitige Klicks oder zwei Personen führen einen Anruf durch. - MeetSiInvitePolicy: Vorgesetzte (Org-Graph-Berichtslinie, Org-Inhaber) immer; andere pro SI's meeting_invite_policy (SUPERVISORS default | TEAM | ORGANIZATION). Wird auf M1 erzwungen und Meetings werden für Personen erstellt Der Picker von M2 und M3 bietet nur eingeladene SIs an (mit "supervised"). - Raum-Lookup auf **************** Theme-Host über ViewerThemeDomain außerhalb jeder Transaktion.
· AIService
Wer diese SI zu Meetings einladen kann, auf deren Anrufoptionen
Kamo Meet "Eine SI einladen" (Eigentümerauftrag 2026-10-26): meetingInvitePolicy (SUPERVISORS default | TEAM | ORGANIZATION) neben den anderen Anruf- und Besprechungsoptionen der SI gelesen und geändert, gleiche Rechte; gespeichert in **************** (DDL **************** MediaService setzt sie durch.
· kamo-shared-library
MeetingInvitePolicy — wer eine SI zu einem Meeting einladen kann; ai_member_call_options deklarieren
Kamo Meet "Eine SI einladen" (Besitzerbefehl 2026-10-26). Die Vorgesetzten einer SI (ihre Berichtslinie über Manager und Der SI-Supervisor edges, der Organisierer) kann es immer einladen; seine eigene meeting_invite_policy bestimmt, wer sonst noch: SUPERVISORS (Standard), TEAM (benanntes Team, derselbe Manager, seine Berichte) oder ORGANIZATION.Schließt den Graphen nicht ab. AiMemberCallOptionsRow deklariert die von Hand erstellte Tabelle ai_member_call_options (und die neue Spalte) so: KamoInitializer Sie können es aus Code erstellen.
· MCPGatewayService
Games_* - ein SI spielt Schach mit Mitgliedern
SITP TPGAMES. Elf Tools über MediaServices Schach-Endpunkten, als Das Mitglieder-Board ist (Schach-App + PLAY_CHESS, wieder downstream): games_list, games_get_state (Diagramm, FEN, legale Züge, Zugtext, Rekord), games_invite (optionale Fähigkeit), games_join, games_decoder, games_move (SAN oder Quadrate, validiert serverseitig), games_offer_draw, games_decoder_draw, games_resign, games_rematch, games_set_skill. Die Züge des SI werden sonst von MediaService's Engine; das Modell spricht. Interne Schreibzugriffe: nein chat_read nennt das Spiel auf dem Server, auf dem das Spiel gespielt wird Eine GAME_INVITE-Karte. Genehmigungsphrasen + CHESS_GAME-Substantiv; games_ Präfix; goldens Regeneriert (11 hinzugefügt). Tests: GamesPackTest 7, ChatPackTest +1; vollständige Suite 1968 grün.
· EmailService
Eine Klartext-Version neben dem HTML und ein Recap-Brief des SI für einen Supervisor, wenn der SI kein Postfach hat (TPRECAPS)
/api/email/send nimmt einen optionalen textBody: der Körper ist dann mehrteilig/alternativ (Text, dann das HTML), innen gemischt POST **************** (KamoAI geheim, mehrteilig wie /api/email/send) Sendet einen Brief, dessen Aufrufer als Transaktionsmail der Organisation erstellt wurde: NoReply@ seine Domäne nur, wenn diese Domäne SPF autorisiert uns, ansonsten die Plattform unter ihrem Namen, mit der Textversion und bis zu zwei Dateien.
· kamo-shared-library
Deklarieren Sie ai_call_recap und ai_member_recap_options für die SI-Anruf-Zusammenfassungs-E-Mail (TPRECAPS)
Eine Zeile pro SI-Telefonanruf, der eine Konversation hatte, sodass die Zusammenfassung den Vorgesetzten einmal erreicht; und die zweite Zusammenfassung eines SIs Beide Optionen sind standardmäßig aktiviert. Hand-applied DDL (kamoai-service **************** Hier deklariert, damit KamoInitializer es neu erstellen kann.
· MCPGatewayService
Jedes SI hat eine Uhr: time_now, time_convert, time_calc
Besitzerbericht 2026-10-26: Bei einem Anruf nach der Uhrzeit gefragt, ein SI sagte, es habe keine Uhr Kalender, den jede Person hat: die Zeit jetzt in der SI-Zone oder einer anderen (mit dem Tag der Woche), eine Zeit in einer anderen Zone gesagt, und Datum arithmetisch. Liest, kein Recht, keine Aufzeichnung.
· MCPGatewayService
Die nachgewiesene E-Mail eines Teamkollegen an einen SI ist seine Anfrage und seine Bestellung
Besitzerbericht 2026-10-26: der Besitzer hat seine SI per E-Mail angeschrieben, um sie anzurufen; die E-Mail war nie ein Bestellung ([ORDER] keine Bestellung) und jeder spätere Check-in liest es als Außenpost und fragte die Mail EmailService beweist, dass das eigene Postfach eines Teammitglieds, das an die SI gesendet wurde, nun Innerhalb einer Mail (sentByTeammate, internal taint) und einer Nachricht wie einer Chatnachricht: Autor, Aktualität, Laufzeit und Beschädigung werden geprüft. Eine gefälschte Absendung bleibt außerhalb der Post.
· MediaService
Ein SI-Mitglied spielt Schach mit Mitgliedern, deren Züge von Kamos Engine ausgewählt werden
SITP TPGAMES (Besitzer 2026-10-26: ein SI, der gebeten wurde, Schach zu spielen, wusste nicht, wie). - ChessSiPlayer: ereignisgesteuert (ChessTurnEvent nach jeder übertragenen Änderung). Einladung eines Mitglieds: Das SI tritt bei und sein Geist wird einmal geweckt (ein Chat Benachrichtigung auf der Konversation der Karte), um sie zu begrüßen Angebot: akzeptiert, es sei denn, der SI ist um mehr als einen halben Bauern voraus. ChessAi (alpha-beta + Ruhe, zeitlich budgetiert) wählt den Zug am SI's Level und es wird als SI über ChessGameService.move gespielt, der ~0.7 s Pause, eine ausstehende Aufgabe pro Spiel, 100% der Zeit auf der Karte verbracht 200 pro Pod, Redis Anspruch über Pods hinweg, FEN vor dem Schreiben erneut geprüft. - ChessSiEligibility, jeder Zug: Schach-App an, PLAY_CHESS angewendet, Laufzeit Nicht PAUSED/BLOCKED/RETIRED. - Recovery Sweep (Singleton, 30 s) für eine Runde einen Neustart oder Pause verpasst. - Keine SI-vs-SI Boards (Einladung abgelehnt; für niemanden wird gespielt). - Skill pro Spiel (CASUAL/CLUB/MASTER, Standard CLUB) in Redis, keine DDL; POST /games/{id}/si-level; schreibt Züge (SAN oder e2e4) auf /move. - Das Board zeigt das Foto des Gegners (opponentAvatarUrl war immer null), opponentIsSi und siLevel. - Fix: Ein ChessAi, der von jeder Anfrage geteilt wird, hat seine eigenen Deadline-Felder. Tests: ChessSiPlayerTest 11, ChessSiRulesTest 15, Query parse 1; Schach und Spiele Suiten grün (100).
· EmailService
Beweisen, dass ein Teamkollege eine E-Mail eines SI gesendet hat, damit eine per E-Mail versandte Anfrage als seine Bestellung zählen kann
Ein interner Endpunkt beantwortet, ob eine Nachricht im eigenen Postfach eines Mitglieds von einem Teammitglied: sein Von erreicht ein Mitglied derselben Organisation, und der eigene Ordner "Send" dieses Mitglieds enthält Eine gefälschte Nachricht wird nie weitergeleitet; sie ist schreibgeschützt.
· kamo-internal
Pipeline zeigt, wann jeder Deal und jedes Darlehen eröffnet wurden, und sortiert danach
Deals und Leihgaben zeigen "Geöffnet <Datum, Uhrzeit>" im Mitgliederbereich. Für Leihgaben Importiert von Arive, das ist die Erstellungszeit von Arive - vorher, jedes importierte Der Deal wird so sortiert, wie er am Tag des Imports eröffnet wurde.
· SecurityService
Pipeline-Darlehen, die in Arive eröffnet wurden, tragen die Erstellungszeit von Arive, nicht die des Imports
· kamo-shared-library
Darlehenszusammenfassungen tragen, wenn ein MLOS-Darlehen wirklich eröffnet wurde (openedAt)
· kamo-internal
Perspektiven – Pre-Application-Deals verlassen die offene Pipeline
Ein Geschäft, dessen Darlehen alle bei der Aufnahme, Qualifizierung oder Vorabgenehmigung sind (keine Anwendung noch nicht übernommen) zeigt unter eigener Prospects-Ansicht und Zählung. Öffnen, Die KPIs und die Bühnenschiene zählen nun nur noch laufende Anwendungen; Kamo's Eigene Entwürfe bleiben in Open. An den Leihgaben ändert sich nichts.
· kamo-internal
Pipeline zeigt Vorantragsphasen, jedes Ergebnis und archivierte Darlehen
- Status: Bewerbungseingang, Qualifizierung, Vorabgenehmigt; Genehmigt Nicht Akzeptiert, wegen Unvollständigkeit geschlossen, aufgehoben, Vorabgenehmigung verweigert / Nicht akzeptiert – eine gemeinsame Liste anstelle von zwei fest codierten Kopien - Board und Deals: Archivierte Leihgaben verlassen die offene Pipeline (unter Vergangenheit angezeigt, Archiviert gekennzeichnet); nicht finanzierte Ergebnisse gelten als storniert - "submitted" ist nicht mehr statusId >= 2 (id's sind Identitäten, nicht Bestellung) - Arive Stadiumskarte bietet die Voranwendungsstatus
· SecurityService
Kamo hält jedes Arive Darlehen, beim Status Arive hat es wirklich
- Import- und Inbound-Ereignisse übernehmen jedes Darlehen - offen, finanziert, ungünstig oder archiviert — statt nur "aktive" - kein Get Loan- oder crmReferenceId-Stempel pro Leihgabe: Jeder ist eine Zapier-Aufgabe auf der Plan des Kunden (20.000+ für einen Import); die GUID erkennt das Darlehen - Die Daten von Arive werden als Datensatzsystem angewendet (gelöscht, wenn Arive keine, z.B. ein Bewerbungsdatum auf einer Vorbewerbungsdatei) - eine Stufe hinter Kamo wird neu ausgerichtet, auf der Platte, anstatt abgelehnt - Entwurf-only-Guards (Borrower-Bearbeitungen, eigene Einreichung, SI-Credit-Pull / AUS) abdecken Die Vorantragsphasen; "submitted" ist nicht mehr statusId >= 2
· kamo-shared-library
Status vor der Bewerbung, jedes HMDA-Ergebnis, Archiv und Arives tatsächliche Daten
Arive Darlehen wurden allein anhand der Phasennamen abgebildet: jede Vorantragsphase wurde Application Taken, alle archivierten Darlehen wurden zurückgezogen (auch die finanzierten), Jede nachteilige Aktion wurde abgelehnt, und die Daten wurden mit dem Importtag gestempelt. - LoanFileStatus (angehängt — Ordnungsspalte): APPLICATION_INTAKE, QUALIFICATION, PRE_APPROVED; Ergebnisse APPROVED_NOT_ACCEPTED, UNKOMPLETT, PREAPPROVAL_DENIED, PREAPPROVAL_NOT_ACCEPTED, PREAPPROVAL_NOT_ACCEPTED - Zustandsmaschine: optionale Voranwendungspfeile; jedes Ergebnis nur aus der Status, denen es folgen kann - LoanFile.archivedAt: archive ist ein Flag neben dem Status, kein Ergebnis - Arive: ADVERSE-Stadium + AriveAdverseReason-Zuordnung zu ihrem eigenen Ergebnis (beide Leih-Einrichtung = Antrag genommen, Offengelegt = In Bearbeitung; Daten von Arive (TRID-Datum, unterzeichnete Dokumente, Finanzierungsdraht, Bühnendaten), nie heute - realignToExternal: das externe MLOS ist das Datensatzsystem für die Bühne - HMDA-Aktion aus dem tatsächlichen Ergebnis entnommen; in-progress-Dateien haben keine - Commerce / Transaktionsrollup / Horizont schließen behandeln die neuen Status
· kamo-internal
Externe MLOS lebt auf dem Hypothekenmarkt und auf jedem Kredit
- Einstellungen → POS-Märkte → Hypothekenmarkt: neuer Reiter "Externe MLOS" (Arive über Zapier, MeridianLink) mit Verbindung, Etappenplan, Transaktion Fenster und den Import von aktiven Darlehen; der Lead-Market MLOS-Picker ist Ersetzt durch einen Zeiger darauf - Kreditantrag: eine Statusleiste zeigt den Platz des Darlehens in der externen MLOS (verknüpft / senden / benötigt Felder / abgelehnt), erneut senden und in MLOS öffnen; Abschnitte, die dem MLOS gehören, sind schreibgeschützt, mit einer Notiz, wo sie bearbeitet werden können - Pipeline-Dealkarte: externer MLOS-Chip - Leadseite: Arive/MeridianLink Aktionen entfernt - Proxy-Routen verschieben auf ****************
Euer Universum wartet.
Fügen Sie Produkte hinzu, wann immer Sie möchten – keine Migration, keine neuen Anmeldungen.
Für immer kostenlos – keine Kreditkarte erforderlich