The availability of the Trace API download functionality, currently supported in OutSystems 11, should be extended to OutSystems Developer Cloud (ODC). We already have "Traces" at ODC portal that contains useful information when API fails , however doesn't have the request and response payload. This level of detail is a critical asset for development and troubleshooting. It enables faster debugging of API issues by allowing developers to verify payload correctness, understand provider errors, and ensure that the application complies with contract expectations (all of which are hard to validate without full trace access) Additionally, since OutSystems 11 already offers this functionality, bringing it to ODC would ensure consistency for teams migrating or working across both platforms, improving developer experience and efficiency.

OutSystems is actively supporting integration of ODC and O11. Currently, the only way to consume logic from each other is to use a REST API. This is cumbersome and portentially unsafe. It would be much easier if the Platform allowed consuming Service Actions instead (which in essence are also REST methods, but easier to use). So O11 logic could consume an ODC Service Action, and ODC logic could consume an O11 Service Action. This would greatly enhance easy operability, and be secure out of the box.

As we know, contact centres are underwater everywhere (as SNS24 in Portugal).The idea is to create a chatbot for FAQs that allow people to quickly get relevant information.We can use OutSystems.AI chatbot , integrated with the QnA service and integrated with some oficial knowledge bases (example: https://www.ecdc.europa.eu/en/novel-coronavirus-china/questions-answers ).Unanswered questions can be listed in a page, to be reviewed and added to the knowledge base, to make the chatbot smarter and smarter.The chatbot could then be highly improved if we allow humans to enter the loop and make the experience even smoother.

Currently, when a developer enables a breakpoint in a shared environment (like Dev or Test), all active sessions hit that breakpoint. This disrupts other developers and interrupts their work. Introduce a "Debug My Session Only" toggle within Service Studio. When enabled, breakpoints would only trigger if the request originates from the developer’s own authenticated user session or specific IP address.

I would be great to be able to edit entity data (in addition to the ViewData functionality) inside Service Studio.As far as I know, there is no easy way to manually edit data for testing purposes.This is extremely helpful especially when bootstrapping data from Excel

From LifeTime 11.27.0 version, OutSystems introduced option "Allow newly created applications to be deployed to all environments". Will be good if infrastructure manager, we can further configure that only Administrator with Full Control can unlock new app. Meaning to say, even developer has given Change & Deploy permission, they still not able to see unblock button. Thank you. https://success.outsystems.com/documentation/11/deploying_apps/block_an_app_from_deployment/

For many times we need to check the history of changes to an action or screen, it is also interesting to compare with an earlier version. It would work with the following steps:1 - Click the right mouse button2 - Select the option to view the history3 - View the history with the name, modification date and an option to compare with the current version.Images1 - Option to view history2 - History window with the option to compare with previous versions

Our profile page has an Achievements section. While it is OK for regular users, some community members are too active in the forum for that to be searchable. That page becomes useless after a hundred entries. Can we have a filter like in Activity tab?

Câmera (getUserMedia) trava indefinidamente ao debugar apps mobile no Service Studio/ODC Studio para macOS — causa raiz: falta de entitlement de câmera no app Produto / Componente Service Studio para macOS / ODC Studio para macOS — Debug de aplicações mobile (alvo "Chrome (emulated)") Ambiente macOS: 27.0 (build 26A5378j) Service Studio: 11.55.78.64991 ODC Studio: 1.7.14.10418 Chrome: 150.0.7871.115 (única instalação no sistema, sem Beta/Dev/Canary) Máquina: MacBook pessoal (não gerenciada por MDM), câmera integrada (MacBook Pro Camera) Resumo do problema Ao iniciar uma sessão de debug no Service Studio/ODC Studio com o alvo "Chrome (emulated)", qualquer chamada a navigator.mediaDevices.getUserMedia() na página fica pendente para sempre — a Promise nunca resolve nem rejeita. Não aparece nenhum prompt de permissão de câmera, nenhum erro no console, e chrome://media-internals → aba "Players" nunca registra sessão de captura alguma (fica "No media player logs" indefinidamente). O mesmo fluxo/URL funciona perfeitamente quando aberto manualmente em uma janela normal do Chrome (fora do Service Studio) — câmera abre e renderiza sem problemas. Impacto Não é possível debugar (breakpoints, inspeção de rede/console via Service Studio) nenhuma tela que dependa de câmera/getUserMedia — inclui fluxos de reconhecimento facial, liveness, upload de foto via captura direta, etc. — usando o Chrome (emulated) integrado ao Service Studio para macOS. Passos para reproduzir Abrir um módulo mobile/reactive com uma tela que chama getUserMedia (ex.: captura de câmera para liveness). Na aba Debug Setup, com "Entry Module: (this module)" e browser "Chrome (emulated)" (única opção disponível), clicar em Start debugging. Navegar até a tela que solicita a câmera. Observar: nenhum prompt de permissão aparece; a tela fica travada (spinner/preto); nenhum erro no console. Investigação já realizada (causa raiz identificada) Passamos por um processo de eliminação completo antes de chegar à causa raiz — resumo dos testes: Verificado que getUserMedia é de fato chamado (interceptado via console) — a Promise fica em estado pending para sempre, sem resolver nem rejeitar. chrome://media-internals → Players: sempre vazio ("No media player logs") durante o travamento — a chamada nunca chega a criar uma sessão de captura rastreável. Descartado: constraints de câmera — constraints usadas (640x480 ideal) são suportadas pelo hardware (confirmado em chrome://media-internals → Video Capture: câmera enumerada corretamente via AV Foundation, múltiplas resoluções). Descartado: iframe / Permissions Policy — elemento de câmera não está em iframe. Descartado: perfil efêmero / modo Convidado (--bwsi) isoladamente — reproduzimos a linha de comando exata usada pelo Service Studio (capturada via ps aux durante uma sessão de debug ativa): /Applications/Google Chrome.app/Contents/MacOS/Google Chrome \ --remote-allow-origins=* --ignore-certificate-errors --no-default-browser-check \ --no-first-run --profile-directory=Default --bwsi --test-type \ --remote-debugging-port=9222 --user-data-dir=/ChromiumAdapterTemp/ \ --disable-search-engine-choice-screen Ao lançar essa mesma linha de comando manualmente pelo Terminal (usuário, não Service Studio) — incluindo --bwsi, --remote-debugging-port (CDP) e perfil novo em $TMPDIR — a câmera funcionou normalmente em todos os testes isolados e combinados. Ou seja, nenhuma flag do Chrome usada pelo Service Studio é, por si só, a causa. Descartado: política/permissão de câmera — testamos inclusive forçar auto-concessão via política gerenciada do Chrome (VideoCaptureAllowedUrls, aplicada e confirmada em chrome://policy com status OK dentro da própria instância do Service Studio) — não teve efeito; media-internals continuou sem nenhuma sessão registrada. Causa raiz encontrada — falta de entitlement de câmera no processo pai: Inspecionamos a assinatura de código dos apps instalados: codesign -d --entitlements :- /Applications/ServiceStudio.appcodesign -d --entitlements :- "/Applications/ODC Studio.app" Resultado: nenhum dos dois declara NSCameraUsageDescription no Info.plist, e nenhum dos dois tem o entitlement com.apple.security.device.camera. Ambos rodam sob Hardened Runtime (com.apple.security.cs.allow-jit, allow-unsigned-executable-memory, allow-dyld-environment-variables), sem App Sandbox completo. Quando o Service Studio/ODC Studio lança o Chrome como processo filho para o debug ("Chrome (emulated)"), o macOS TCC (Transparency, Consent and Control) atribui a decisão de autorização de câmera ao processo responsável (o próprio Service Studio/ODC Studio, via o mecanismo de "responsible process"). Como esse app nunca declarou intenção de uso de câmera nem tem o entitlement correspondente, o TCC não tem como resolver o pedido do processo filho — não autoriza, não nega, não mostra prompt algum. A Promise do getUserMedia() fica pendente indefinidamente. Isso explica por que a mesma URL, com as mesmas flags de Chrome, funciona quando lançada pelo usuário (via Terminal ou Dock) — nesses casos o processo responsável não é o Service Studio, então não há a mesma lacuna de entitlement na cadeia. Bundle IDs afetados com.outsystems.servicestudio.launcher (ServiceStudio.app) com.outsystems.odcstudio.launcher (ODC Studio.app) Correção solicitada Adicionar ao build macOS do Service Studio / ODC Studio: NSCameraUsageDescription (e idealmente NSMicrophoneUsageDescription, caso fluxos de vídeo com áudio também sejam afetados) no Info.plist O entitlement com.apple.security.device.camera (e com.apple.security.device.microphone se aplicável) na assinatura de código para que o processo Chrome filho, lançado para debug ("Chrome (emulated)"), consiga negociar corretamente a autorização de câmera junto ao macOS TCC. Workaround atual (client-side, sem alteração do produto) Não há workaround dentro do Service Studio. Para continuar testando telas dependentes de câmera enquanto o fix não sai: usar "Chrome (emulated)" apenas para a lógica antes/depois da tela de câmera; para a tela em si, copiar a URL gerada pelo debug e abrir manualmente em uma janela de Chrome iniciada pelo próprio usuário (fora do Service Studio) — confirmado funcionando em todos os testes, mas perde a sincronia de breakpoints visuais do Service Studio nessa tela específica.

It would be great to be able to create static entities from an external library if support was added to the external library SDK for this. We only use ODC so this is specific to that but maybe has application to O11 but I don't enough about O11. Adding this capability would significantly improve the ability to deliver higher quality external libraries that are more powerful and OutSystems compatible. In addition, it might actually translate in to more revenue for OutSystems so a win-win scenario.