Professional account variants
Model the connected account variant as product state so the right workflow is offered to the right account holder.
Professional-network architecture
Give recruiting, relationship, and customer-initiated networking workflows a visible path from connection eligibility to account recovery.
Professional network connection architecture
Make account ownership, project context, health state, and recovery visible to the customer instead of burying the integration behind an opaque setup step.
Model the connected account variant as product state so the right workflow is offered to the right account holder.
Start each request in a named workspace and project, then retain approval and readiness signals with the account.
The product workflow
Explore the original Moira surfaces for the path from a customer-controlled connection to an observable workflow, with capability and recovery context alongside it.
Connection control plane
Moira keeps connected-account health, project-scoped credentials, delivery evidence, and a safe recovery route together in the customer console.
Explore the product
Use cases
Use the provider as part of an ATS, CRM, or outreach workflow while retaining project and capability context at every step.
MMaya ChenConnection context updated
DDaan BakkerHealth state needs review
AAmara SinghProject event observed
Keep LinkedIn connection context beside candidates, account health, and recruiter-owned recovery actions.
Explore use caseMMaya ChenConnection context updated
DDaan BakkerHealth state needs review
AAmara SinghProject event observed
Put LinkedIn activity alongside the customer record so account teams can investigate the next safe action.
Explore use caseMMaya ChenConnection context updated
DDaan BakkerHealth state needs review
AAmara SinghProject event observed
Make LinkedIn a visible, policy-aware stage in a controlled multi-step outreach workflow.
Explore use caseDeveloper integration
Associate each signal with a project, account, provider state, and recovery path. The result is an operable integration rather than a disconnected API response.
Read developer documentationconst event = await moira.events.verify({
projectId, provider: "linkedin",
eventId: request.headers.get("x-moira-event-id"),
});
if (event.state === "attention_required") {
await queueRecoveryReview(event);
}Trust work in progress
These are current in-progress programs, not completed certifications, compliance guarantees, or a substitute for your own assessment.
Integration questions
Answers describe product boundaries and operational recovery without making provider capability promises.
A workspace member begins in the intended project context. Moira presents only the connection path and account state that the live provider registry and workspace policy permit.
No. The page describes an integration architecture. Actual availability remains subject to configured provider paths, account state, entitlement, project policy, and provider terms at the time of use.
The customer console is designed to present account health, the specific recovery route, and the relevant project context. Operators should follow that route rather than retrying a blind action.
Moira keeps provider outcomes and event references available beside the workflow so a product can distinguish requested, observed, and attention-required states.
Professional-network data is handled only for the connected account, requested workflow, and configured project boundary. Moira does not turn public-profile architecture content into an independent contact database.
Event-oriented integrations should retain an identifier, delivery boundary, and retry context. Downstream systems should decide on recovery from evidence instead of replaying an uncertain operation.
Moira is progressing through a SOC 2 Type II audit and an ISO 27001 certification program, while operating a GDPR-focused privacy program. These are in-progress initiatives, not completed certifications or a guarantee of suitability for a particular use case.
Start by defining project scope, the customer-owned connection path, event contract, and recovery model. Then use the customer console and developer documentation to check live readiness.
Provider path
A useful integration does not stop at authorization. It makes the current boundary, account state, and recovery route legible inside your product.
Keep customer-initiated networking communication traceable to the connected account, project, and delivery outcome.
Represent eligibility, requested action, provider response, and any next recovery step as distinct operational stages.
A recruiter or relationship manager can see whether an account needs approval, reconnection, or a different workflow before proceeding.
Start with the right boundary
Model the connected account variant as product state so the right workflow is offered to the right account holder.
Start each request in a named workspace and project, then retain approval and readiness signals with the account.
Product workflows
Connected conversations
Relationship workflows
Account state projected
evt_01Event envelope received
evt_02Delivery evidence recorded
evt_03Recruiting and sales context
Availability is checked at connection time.
Capability boundaries
Every category communicates its readiness state in words, not colour alone.
Build with context
Keep connection state, event evidence, and security boundaries in the implementation path from the start.
Data-handling boundaryProfessional-network data is handled only for the connected account, requested workflow, and configured project boundary. Moira does not turn public-profile architecture content into an independent contact database.
Architecture questions
A workspace member initiates a connection in the intended project context. Moira presents only the authorization path and capability state that the control plane permits.
The account health and capability state becomes visible in the customer console. A customer or operator can follow the specific reconnect, approval, or policy-recovery route instead of retrying a blind action.
No. This page explains the integration architecture. The live provider registry, workspace policy, and provider terms decide whether a connection or action is available at execution time.
Start with verified readiness