How to Turn Court Publications into Service Orders: 5 Low-Code Automations

A reliable workflow starts with a minimum data contract. Before connecting a feed to an ERP, CRM, case manager, or service desk, define which fields are mandatory and which may be enriched later. This prevents a low-code scenario from creating a technically valid order that a lawyer cannot actually use.

The source identity should include the case number, court or journal, instance when available, publication date, availability date, and a stable publication identifier. If the source system supplies a URL, document reference, or event identifier, preserve it. A title such as "new publication" is not enough to support deduplication or later audit.

The action layer should contain the extracted obligation, suggested task type, responsible team, legal owner when known, due date, time zone, priority, and escalation rule. Store the confidence level of any AI extraction as a separate field. A deadline identified with low confidence should go to review rather than directly to execution.

Context is equally important. Include the party or monitored name, matter identifier, client or business unit, a short summary, the relevant excerpt, and links to the full publication and process history. Avoid placing sensitive content into systems that do not need it, and define retention and access rules in line with the Brazilian General Data Protection Law.

A practical minimum schema looks like this: source_id, process_number, publication_date, available_date, event_type, action, due_date, owner, priority, confidence, source_url, source_hash, order_version, and audit_status. The exact names can vary, but the meaning must remain stable across integrations.

The workflow can be implemented in five layers: capture, enrich, decide, execute, and observe. Capture receives the publication from the monitoring platform. Enrich adds the process history, documents, AI summary, and extracted fields. Decide applies business rules. Execute creates or updates the service order. Observe records what the workflow did and whether a person changed the result.

For a webhook-based setup, the trigger can be a new publication event from the Pocket Jurídico API. In a Make scenario, the webhook receives the event, a JSON parser validates the schema, an AI module extracts action fields, and an HTTP module calls the target ERP. In Power Automate, the same pattern can use an HTTP trigger, condition blocks, an approval action, and a custom connector. Make documents its webhook behavior in its official webhook documentation, which is useful when deciding between instant and scheduled processing.

MCP can add a conversational control layer without replacing governance. An authorized user might ask an AI assistant to find all publications with response deadlines within five business days, summarize the relevant process history, or propose an order. The MCP connector should expose only the operations the user needs, and order creation should require structured validation or approval when the consequence is material.

A normalized payload sent to a service-order endpoint could look like this:

{
 "idempotency_key": "pocket-2026-abc123-response-v1",
 "source": "pocket_juridico",
 "source_publication_id": "abc123",
 "process_number": "0001234-56.2026.8.26.0100",
 "event_type": "deadline_identified",
 "action": "Prepare and file response",
 "summary": "The court publication requires a response within the applicable procedural deadline.",
 "available_date": "2026-10-29",
 "due_date": "2026-11-05",
 "priority": "high",
 "owner_group": "Corporate Litigation",
 "confidence": 0.93,
 "source_url": "https://example.invalid/publication/abc123",
 "order_version": 1,
 "requires_human_review": false
}

The URL above is illustrative and should be replaced with the real source URL supplied by the monitoring system. A TOTVS adapter may map action to the service description, process_number to a custom matter field, and idempotency_key to an external reference. A ServiceNow adapter may map the same values to short_description, description, due_date, assignment_group, priority, and correlation_id.

For a ServiceNow-style request, the body could be shaped as follows:

{
 "short_description": "Prepare response, case 0001234-56.2026.8.26.0100",
 "description": "Publication summary: The court publication requires a response. Source ID: abc123. Review the attached process context before filing.",
 "correlation_id": "pocket-2026-abc123-response-v1",
 "due_date": "2026-11-05",
 "priority": "2",
 "assignment_group": "Corporate Litigation",
 "u_process_number": "0001234-56.2026.8.26.0100",
 "u_source_publication_id": "abc123",
 "u_order_version": 1
}

Do not send a publication directly to a create endpoint without a lookup step. The low-code scenario should first query by correlation or external reference, branch if a match exists, and only then create a new order. For updates, compare the incoming hash and version against the stored record to distinguish a repeated event from a meaningful change.

Consider a retail legal department monitoring a high volume of consumer and commercial litigation. Before automation, an analyst reviews publications, copies process numbers into a spreadsheet, emails regional counsel, and later checks whether someone created a task in the corporate system. In a representative workflow measurement, 180 publications may produce 42 actionable items, consume about 18 analyst hours per week, and generate six duplicate tasks when the same matter appears through different channels.

After normalization and idempotent routing, each actionable item receives one external reference, one owner group, one deadline, and one source link. The analyst reviews only low-confidence or high-impact items, reducing the modeled workload to roughly seven hours per week and eliminating the six duplicate tasks from the measured sample. These figures are planning examples, not a universal benchmark, so each department should establish its own baseline.

A boutique litigation firm presents a different pattern. Its lawyers may handle fewer matters but need richer context, including procedural history, documents, client comments, and internal decisions. The main waste often comes from reading the same publication several times and creating parallel reminders in email, a calendar, and a case spreadsheet.

In a controlled pilot involving 60 new publications, the firm can route routine updates to a monitoring queue and reserve service orders for concrete actions such as filing, collecting documents, or contacting a client. If 15 of those publications require work, the team can compare the time spent manually creating 15 tasks with the time spent reviewing 15 prefilled orders. The meaningful success measure is not simply fewer clicks. It is fewer duplicated decisions and a clearer audit trail.

Pocket Jurídico is suited to this validation layer because it monitors publications and procedural movements across more than 490 journals and courts, validates the process across instances, and presents history, documents, and movements around the publication. Its API, AI connections, and MCP options can feed the low-code workflow, while comments and alerts keep operational context with the process instead of scattering it across email and spreadsheets.

The first mistake is treating every publication as a task. Many publications provide information but do not require an immediate operational action. A better design distinguishes informational events, monitoring events, review events, and execution events, each with a different level of automation.

The second mistake is trusting an extracted deadline without checking the source and the organization's calendar rules. Date calculation can depend on availability, business days, suspensions, local holidays, and procedural interpretation. Automation should surface the proposed date and its source, not hide the assumptions behind it.

Another common failure is creating a new order whenever a feed event arrives. Feeds may resend records, different instances may reference the same case, and a publication may be enriched after its first delivery. Idempotency, content hashes, and versioned updates are essential safeguards.

Access control also deserves attention. A connector should pass only the data required by the destination and should use service accounts with the smallest practical permissions. Review the NIST Cybersecurity Framework 2.0 for a useful structure covering governance, identification, protection, detection, response, and recovery.

Finally, do not measure automation only by the number of orders created. A system that creates more tasks can increase noise. The stronger indicators are actionable-order precision, duplicate suppression, time saved, review quality, deadline reliability, and whether lawyers can reconstruct the decision from the publication through completion.