Sistemas de negócio
Processos, permissões e banco independentes, em computador local ou nuvem conforme o plano.
InícioRUNLUME / PLATFORM
Plataforma
Dos métodos em produtos à integração, ativação e operação: veja como identidade, ciclo de vida, direitos e conexões sustentam a jornada completa do SaaS independente.
INDEPENDENT APPS. SHARED FOUNDATIONS.
Aplicativos independentes, base consistente.
Runlume conecta uso e operação do SaaS: a equipe acessa aplicativos com clareza e desenvolvedores preservam produto, código e dados. Não é hospedagem de código de negócio nem um banco que reúne todas as operações.
Aplicativos oficiais
Recursos de negócio maduros sob demanda
Sistemas próprios
Preserve código, dados e implantação independente
Sistemas de terceiros
Integre por interfaces e autorização claras
Runlume.
Identidade unificadaDireitos da assinaturaIntegração autorizadaColaboração com agentes
Conecte recursos sem fundir bancos. Chamadas respeitam tenant, instância e autorização de dados.
Veja recursos e divisão de papéis. Funções, integração e regras comerciais seguem plano, configuração e acordo.
Conhecer padrões de comunicação e dadosINSIDE THE PLATFORM
Veja a base comum de gestão pelas telas.
Diretório organizacional e autorização têm papéis distintos. Vínculos não concedem acesso a dados automaticamente.
Estrutura organizacional
Runlume.Espaço de demonstraçãoTela ilustrativa
Organização e membrosExemplo · Não é em tempo real
Shushen Tecnologia · Sede de demonstraçãoDesenvolvimento de produtosMarketing e vendasAtendimento ao cliente
Membros de demonstraçãoDepartamentoFunção
Membro ADesenvolvimento de produtosResponsável pelo produto
Membro BMarketing e vendasGerente de contas
Membro CAtendimento ao clienteEspecialista de atendimento
Telas e dados apenas ilustram o uso, sem representar operação real ou compromisso funcional.
Autorização de recursos
Runlume.Espaço de demonstraçãoTela ilustrativa
Autorização de recursosExemplo · Não é em tempo real
Chamador: gestão de clientes→Provedor: gestão de conteúdo
Ler conteúdo publicado
content.delivery.readSomente leitura no escopo acordado, sem editar ou excluir.
Exemplo de autorização explícitaNovas interfaces não herdam autorização automaticamente.
Telas e dados apenas ilustram o uso, sem representar operação real ou compromisso funcional.
SYSTEMS / PLATFORM / OPERATIONS
Sistemas independentes, responsabilidades claras.
Ilustração dos papéis: a plataforma conecta recursos comuns; sistemas cuidam do negócio e dos dados. Integração não exige um único banco.
Plataforma Runlume
Identidade, organização, direitos, ativação, autorização explícita e registros.
Responsáveis pela implantação e operação
Confirme rede, backup, recuperação, monitoramento, atualizações e incidentes.
Sistema de negócio ← Contratos e autorização claros → Plataforma Runlume; cada responsável mantém seu ambiente
THE SHARED FOUNDATION
Recursos que sustentam o negócio
Da implementação de métodos à operação, é necessária uma base comum. Runlume conecta identidade, organização, ciclo de vida, assinaturas, sistemas, recursos e segurança para independência com colaboração organizada.
01
Identidade e estrutura organizacional unificadas
Um login, acesso claro aos aplicativos permitidos.
Identidade comum não dá permissões iguais a todos; organiza contas, membros e acessos. O primeiro login pode criar a conta automaticamente, sem cadastro separado.
- Autentique-se na entrada comum e acesse aplicativos autorizados.
- A plataforma gerencia empresas, departamentos, equipes e vínculos. Sistemas que adotam seu diretório podem ler relações e mudanças com autorização, reduzindo duplicação. Organização não substitui permissões de negócio.
- Diferencie usuário da plataforma, conta vinculada e instância; um login não autoriza todos os espaços.
- A plataforma gerencia entrada; o aplicativo valida a visibilidade dos dados específicos.
No contexto do negócio
A equipe usa a mesma identidade no CRM e em Pedidos, mas consultar um cliente ou alterar um pedido depende das permissões de cada aplicativo.
Limites dos recursosLogin bem-sucedido não significa todos os aplicativos ativos ou acesso a todos os dados.
02
Ativação e ciclo de vida de aplicativos
Da ativação à saída, estados claros para cada aplicativo.
A plataforma gerencia o uso por instâncias, além de links. Ativação, suspensão, retomada e saída são executadas pelo sistema via interfaces acordadas, com estado registrado.
- Relacione a instância da conta ao espaço próprio do sistema.
- Controle acesso pelo estado: disponível, em processamento ou suspenso.
- Mantenha estado e continuidade para operações lentas ou falhas, sem confundir solicitação com conclusão.
No contexto do negócio
Ao ativar CRM, a plataforma cria a instância e o CRM cria o espaço e retorna o resultado. O uso só é liberado quando as condições acordadas são atendidas.
Limites dos recursosAtivação não é hospedagem de código ou implantação de servidores pelo Runlume. Dados no encerramento seguem o aplicativo e o acordo.
03
Cobrança de assinaturas e direitos de uso
Relacione o que foi comprado ao que pode ser usado.
Plano, assinatura, permissões e cotas precisam coincidir. A plataforma aplica regras comerciais às instâncias para servir conforme os direitos vigentes.
- Organize compras por produto, plano e assinatura, sem agrupar obrigatoriamente os cinco aplicativos.
- Separe disponibilidade da função e quantidade de recurso, sem confundir habilitação e consumo.
- Relacione direitos, uso e faturas para renovação, limites e conferência.
No contexto do negócio
Uma assinatura pode incluir funções e cotas. O aplicativo executa o negócio; a plataforma gerencia concessão e uso. Preços e cotas vêm do plano oficial.
Limites dos recursosCriar conta não concede tudo gratuitamente. Planos, limites, cobrança e reembolso seguem a publicação oficial.
04
Integração de aplicativos e troca de recursos
O negócio pode colaborar sem misturar os dados.
Sistemas trocam dados e recursos diretamente por conexões autorizadas. O agente também usa os mesmos contratos. A plataforma controla quem chama quem, quais recursos e em qual contexto de tenant e permissão.
- O provedor declara interfaces ou eventos; o chamador usa apenas recursos autorizados.
- Crie vínculos explícitos na mesma conta. Novas interfaces ou permissões não ampliam autorizações automaticamente.
- Registre chamadas e eventos controlados; cada sistema processa seus dados e duplicatas.
No contexto do negócio
CRM e Pedidos colaboram com recursos publicados e autorizados. CRM fornece referência do cliente; Pedidos mantém regras e dados de atendimento. O fluxo depende das interfaces disponíveis.
Limites dos recursosSem banco compartilhado, compartilhamento padrão entre contas ou promessa de transações distribuídas e sincronização imediata de tudo.
05
IA e recursos compartilhados
Recursos técnicos comuns não precisam ser reconstruídos a cada aplicativo.
Além de identidade e assinatura, aplicativos usam IA, notificações e arquivos. A plataforma fornece acesso e regras comuns; cada aplicativo define como aproveitá-los.
- IA da plataforma centraliza modelos, disponibilidade, cotas e registros. O aplicativo não precisa guardar chaves dos modelos da plataforma.
- Notificações são organizadas por destinatário e entrega; o sistema decide quando disparar e para quem.
- Arquivos e outros recursos seguem instância e autorização, conforme o catálogo publicado.
No contexto do negócio
Um aplicativo de conteúdo pode usar IA autorizada para criação e revisar e publicar por seu fluxo. IA não substitui responsabilidade ou permissão de publicação.
Limites dos recursosIA da plataforma e IA própria do aplicativo têm cobranças distintas. Recursos comuns não permitem à IA contornar autorização e ler todos os dados.
06
Segurança e governança operacional
Limites para cada acesso, autorização e alteração.
Mais aplicativos exigem governança consistente. A plataforma relaciona contas, instâncias, permissões, estados e registros, sem substituir a responsabilidade de segurança de cada sistema.
- Isole por conta e instância, usando contexto de identidade e chamada verificado.
- Autorização, direitos e estado determinam a execução; login não é passe livre a todas as interfaces.
- Registre operações e chamadas importantes para consulta. Credenciais e cargas sensíveis não devem aparecer em logs comuns.
- License gerencia versão, ambiente, quantidade e prazo de implantação privada, separadamente de assinaturas e autorização de acesso.
No contexto do negócio
Após suspensão ou revogação, novos acessos precisam satisfazer as restrições. Registros ajudam a rastrear o processamento em diagnósticos.
Limites dos recursosGovernança comum não significa risco zero ou certificação. Aplicativos ainda precisam implementar permissões, isolamento e retenção locais.
SHARED CONTRACTS. CLEAR DATA.
Sistemas independentes, regras comuns para comunicação e dados.
A base regula autenticação, interfaces, dados e eventos, além das entradas. Contratos sobre padrões públicos permitem colaboração entre tecnologias, reduzindo explicações e conversões repetidas.
Contratos padronizados de comunicação e eventos
HTTP/JSON transporta chamadas; OpenAPI descreve solicitações e respostas; OIDC/OAuth 2.0 apoia identidade e autorização; CloudEvents padroniza eventos. Unificação significa regras comuns, não a mesma linguagem de programação.
- Interfaces versionadas definem entradas, saídas, erros e compatibilidade.
- Identificadores, origem, tipo e carga descrevem mudanças, com registros de entrega e idempotência para acompanhar colaboração.
- Chamadas e assinaturas de eventos seguem conta, instância e autorização de recursos; padrões não dispensam permissões.
Limites dos recursosIntegração ainda exige adaptação, validação de versões e autorização. Padrões não garantem conexão sem ajustes, entrega única de eventos ou chegada em tempo real.
Padronize formatos para apoiar análises
JSON Schema descreve campos, tipos e validação; contratos de API e eventos definem versão, origem e contexto. Entradas consistentes reduzem conversão e organização, apoiando agregações autorizadas, análise e comparação de indicadores.
- Padronizamos troca e descrição; cada sistema mantém domínio e banco próprios.
- Alinhe significado, período, unidades e indicadores antes de analisar. Estrutura igual não implica significado igual.
- Selecione campos pela finalidade autorizada e aplique qualidade, retenção e desidentificação necessárias.
Limites dos recursosIsso não agrega dados de clientes por padrão, não funde tenants nem cria data warehouses automaticamente. Ferramentas, escopo e cálculos seguem a solução; resultados dependem de qualidade e método.
RUNLUME AGENT
Um assistente para coordenar todos os seus sistemas de negócios.
O Agente Runlume é o assistente unificado oficial da plataforma. Dentro da autorização do tenant, usa recursos e dados dos sistemas que ele possui para compreender o contexto, executar tarefas proativamente e acompanhar os resultados.
Conheça o assistente unificadoAssistente oficial unificado
SiteCMSGEOCRMOrders
Conecte os sistemas do tenant, não apenas estes cinco.
- Entenda o negócio entre sistemas
- Aja proativamente e acompanhe
- Conecte recursos e dados
CLEAR RESPONSIBILITIES
O comum fica na plataforma; a especialidade, no aplicativo.
Unificamos regras básicas de colaboração, não toda a lógica de negócio.
| Foco | Responsabilidade do Runlume | Responsabilidade do aplicativo |
|---|---|---|
| Identidade e acesso | Autenticação, vínculos e entradas unificadas | Usuários locais, papéis e permissões de dados |
| Ativação e operação | Direitos, estados e acompanhamento de operações | Criação de espaços, funções e entrega do serviço |
| Dados e colaboração | Contratos de recursos, autorização explícita e registros | Bancos independentes, regras de domínio e qualidade |
Os cinco aplicativos exemplificam a aplicação da plataforma, não todos os seus recursos.
COMMON QUESTIONS
Saiba mais sobre integração e dados.
Login unificado dá acesso a todos os aplicativos e dados?
Não. Ele fornece a entrada comum; acesso depende da conta, instâncias ativas e autorização. Dados de clientes e pedidos continuam sujeitos às permissões de negócio de cada sistema.
Protocolo unificado exige a mesma tecnologia em todos os sistemas?
Não. Runlume usa HTTP, OIDC, OpenAPI, JSON Schema e CloudEvents para identidade, interfaces e eventos. Sistemas mantêm linguagem, framework, banco e implantação e adaptam o escopo necessário.
Como o formato unificado ajuda a análise entre sistemas?
Descrições, tipos e validações consistentes reduzem conversões e organização. Ainda é necessário alinhar significado, unidades, períodos e indicadores, além de obter autorização da finalidade. Formato comum não significa agregação automática nem garante conclusões.
Formatos comuns exigem banco compartilhado?
Não. São comuns as regras de troca e descrição, enquanto modelos de domínio e bancos permanecem independentes. A troca ocorre por interfaces autorizadas, sem substituir contratos por banco comum ou consultas cruzadas.
Qual a diferença entre License privada e direitos da assinatura?
A License verifica o direito de implantar e usar o software privado e pode limitar produto, versão, ambiente, identificador de implantação, quantidade e validade. Os direitos da assinatura definem as funções e os recursos adquiridos pela conta. Nenhum dos dois substitui a identidade de login, as permissões da instância ou as conexões autorizadas entre sistemas; ter uma License não dá acesso a todos os dados de negócio.
Como tratar atualizações ou expiração da License?
Confira versão, ambiente e escala autorizados antes de atualizar e renove ou atualize a licença quando necessário. Efeitos da expiração, renovação e manutenção constam da entrega. O SDK verifica assinaturas localmente com chave pública; isso não torna serviços externos offline nem leva revogações instantâneas a ambientes desconectados.