This week we shipped two small but high-impact improvements that reduce everyday friction: easier navigation between related work and predictable outbound email delivery when you use your own SMTP provider. These changes remove clicks that went nowhere and email settings that looked configured but weren’t being used, so your team can triage, hand off, and communicate with less interruption.
Below are the details for each improvement, how they matter in real workflows, and what you need to do (if anything) to pick them up.
Open blocked tasks and SOP runs directly from the dashboard
You can now click task and SOP run titles in the Blocked Items widget to open the corresponding task or run. Previously those titles looked clickable but didn’t navigate; now they take you to the exact item.
Why this matters: when someone flags a run or task as blocked you usually want to inspect it quickly to understand the blocker and make a decision. Jumping from the dashboard into the exact task or run saves time and reduces context switching.
What this gives you right away:
Clickable task and SOP run titles in the Blocked Items widget that open the item directly.
Faster triage with fewer steps between spotting a blocked item and viewing its details, comments, or owners.
Clearer collaboration because you can land teammates directly on the item you’re discussing.
How teams typically use this
Incident response: spot a blocked run and immediately open it to see logs, owner, and history.
Sprint planning: identify tasks blocking progress and navigate straight into them to assign next steps.
Client work: jump directly to the problematic run when you need to share context with a stakeholder.
If you rely on the Blocked Items widget for daily standups or on-call triage, this should shave off a few clicks every time a blocked item appears.
Click through "Blocked By" and "Blocking" from project and sprint pages
When you view a task in the task drawer from project and sprint pages, the Blocked By and Blocking entries now behave as real links and navigate to the related task. Previously those cards appeared interactive but didn’t open the referenced task from sprint or project contexts.
Why this matters: blockers are a relational problem—knowing what a task is blocked by or what it’s blocking matters as much as the task itself. Immediate navigation keeps the thread of investigation intact without manual search.
User-facing improvements included here:
Tap a blocker or dependent task in the task drawer and go straight to it.
Maintain context when reviewing tasks inside a sprint or project view.
Reduce manual lookup when following a chain of blocked tasks.
Example: if Task A shows it’s blocked by Task B, click that entry to open Task B’s drawer and review its assignee, notes, or run history—no extra search required. This is most helpful during sprint grooming and when resolving cross-team dependencies.
Outbound email now follows your SMTP configuration
If you configure SMTP credentials for outbound email (for example by setting your SMTP host), the backend will now use your SMTP provider after you redeploy with those settings in place. Previously, even when SMTP was configured, emails continued to be sent through the default path in some deployments.
Why this matters: many teams use their own SMTP infrastructure or a preferred transactional provider for deliverability, compliance, or branding. When your settings weren’t being used it created confusion and required manual follow-up.
What you need to do to pick this up
Ensure your SMTP settings (host, port, username, password, TLS settings, etc.) are configured in your deployment environment.
Redeploy your OKiDO backend with the SMTP settings present so the service picks them up.
Send a test notification from OKiDO (e.g., a task assignment or run alert) and confirm delivery from your SMTP provider or inbox.
Quick checklist to verify SMTP is active
Verify the SMTP host and credentials are present in your deployment configuration.
Redeploy the service so the backend reads the new settings.
Use the built-in test email or trigger a simple notification to confirm delivery.
If delivery fails, check your provider’s logs for authentication or relay errors and confirm credentials and connectivity.
If you previously configured an SMTP provider but saw messages still going through the default delivery path, re-check your SMTP settings and redeploy—your outbound email should then follow the SMTP provider you supplied.
Making it work for your team
These updates are small on the surface but address two common operational headaches: invisible links and unclear email routing. Both are about trust—trust that a click will take you where you expect and trust that your outbound email settings will actually be used.
Give the new behavior a try in your workspace. If you hit anything unexpected—links that still don’t navigate, or email that doesn’t follow your SMTP settings—send a note to support or open a ticket and we’ll investigate. Your feedback helps us keep the platform dependable for the work you run on it.
