Answers before a team commits.

The common trigger is not only a missing storage place. It is a missing model: nobody knows which information is current, what it represents, what it links to, who owns it, what rule applies, or why a decision was made.

Owarelin is meant for teams that need information to stay understandable whether it starts as a form, a variant, a file, a generated document, a task, or a relationship.

No. Document management starts from files. Owarelin Records starts from modeled information: schemas, variants, metadata, references, views, tasks, access rules, lifecycle, templates, and history.

A file can be attached. A document can also be generated from a template when needed. But many teams may work mainly through forms, variants, and data-oriented views.

Because the expensive part is often not storage or data entry. It is the time spent verifying, asking around, rebuilding relationships, preparing evidence, or correcting work based on incomplete information.

Owarelin is valuable when the organization needs a shared information model, not only another place to put files.

Usually, no. SharePoint and Teams are useful collaboration and file-sharing environments. Many organizations should keep using them.

Owarelin fits when business information needs a model: metadata, owner, status, references, forms, generated documents, rules, approval trace, retention context, and operational lifecycle.

Those platforms are powerful ECM and enterprise content management systems. They can be the right answer for large, heavily governed enterprise programs.

Owarelin is aiming at a different adoption point: a calmer, more focused information workspace for teams that need forms, variants, references, views, workflows, and evidence without turning every improvement into a long ECM program.

Formal records and archives systems are important when classification, retention, and governance are the center of the program.

Owarelin keeps that governance direction, but tries to make it practical inside daily work: forms, capture, search, ownership, references, tasks, workflows, handover, generated outputs, and evidence while people are still using the information.

Yes. In many cases, the realistic path is not immediate replacement. Owarelin can start around one process, one collection, or one painful handover area.

Import/export and migration support are meant to reduce lock-in and make staged adoption possible.

Owarelin Records helps an organization define how its information should be captured, connected, searched, assigned, reviewed, edited, kept, and explained.

It is useful when the work no longer fits cleanly in scattered files, spreadsheets, shared folders, isolated forms, or conversations that disappear after a decision is made.

Core is for a small team that wants to structure one important area properly before expanding.

Team is better when several people need shared views, clearer search, and day-to-day visibility across more information. Business is the better starting point when tasks, generated documents, and import/export are already part of the operation.

Business is the first plan for teams that treat information as active work, not only as something to keep.

Choose it when people need to assign work, produce documents from reliable data, move information in or out, and keep enough capacity for a real operational scope.

Process is for teams where information must move through controlled work: review, validation, escalation, approval, generation, or handover.

Compliance is for organizations that must prove what happened to information over time: what was kept, what was archived, what was removed, and who approved the action.

Start from the use case, not from the feature list. We look at the first area you want to improve, the people involved, the volume, the expected lifecycle, and the level of control needed.

If the scope is still unclear, it is better to discuss it before subscribing than to choose a plan that looks cheaper but does not match the way the team works.

No. Notifications are included as part of the platform foundation. An operational information platform needs to tell people when something requires attention, so notifications are not treated as a separate commercial module.

No. Desktop editing through the local bridge is included. We want users to keep working with familiar desktop tools when files are part of the flow, while Owarelin preserves the information model around them.

Future browser-based office editing may become a paid capability because it requires hosted editing infrastructure.

Import and export tools are planned from Business upward. They are meant for structured movement of information items, metadata, relationships, and files.

Large migrations can still require implementation support, especially when legacy data needs cleaning, mapping, validation, or staged rollout.

No. Internal migration tooling used by Owarelin developers or implementation teams is not sold as a self-serve module.

The customer-facing capability is import/export and migration support, not the internal SDK.

Prices are shown in EUR. Applicable taxes are calculated and displayed before payment so the final amount can be reviewed before subscribing.

Tax treatment can vary by billing location, customer type, and tax identification details.

Yes. Subscriptions can be cancelled. Provider-backed subscriptions can be managed through the customer portal once billing is active.

Depending on the billing state, reactivation may also be possible.

The product direction is to avoid trapping customers. Import/export is planned from Business upward so information, metadata, relationships, and files can be moved in a structured way.

Cancellation and data deletion are separate events. The exact retention window and export process should be reviewed before cancellation when the information is business-critical.

A failed or unresolved payment can move the subscription into a suspended state. Paid capabilities may be limited until the billing issue is resolved.

The goal is to protect service continuity without hiding the commercial state from the customer.

Yes. Plans include a base number of users and storage. Extra users and storage packs are intended for teams that grow before they are ready to change plan.

If growth changes the operating model, it may be cleaner to move to the next plan rather than stacking many add-ons.

The first step is to understand the real problem: what the team tracks today, where the information breaks down, who needs to act, and what must become easier to prove or retrieve.

From there, a demo should be framed around your case, not around a generic tour of every screen.

Yes, for focused operational scopes where the model is clear and the expected work is understood. We prefer a controlled first deployment over pretending every organization should start with a massive rollout.

Some advanced needs may require discussion, configuration, or roadmap alignment, especially around dedicated hosting, on-premise deployment, large migrations, or future browser-based office editing.

Not always. Smaller teams can start with one focused area and a clear operating model. Larger organizations usually benefit from a short discovery phase to define scope, responsibilities, access, documents to generate, and lifecycle expectations.

Support depends on the plan and the commercial relationship. For early customers, we prefer direct, practical exchanges around concrete use cases rather than generic onboarding material.

Owarelin can be discussed in three deployment models: shared-runtime SaaS, dedicated hosted tenant, and on-premise licensing.

Shared SaaS is the default for fast adoption. Dedicated hosted tenants are for customers that need stronger isolation while Owarelin still operates the service. On-premise is for organizations with strict security, compliance, sovereignty, or internal-network requirements.

Dedicated hosted and on-premise deployments require a separate commercial and implementation agreement because support responsibilities, updates, security controls, infrastructure, and rollout scope vary by customer.

Owarelin is designed around access control, structured information, and clear responsibility. The exact configuration still depends on the customer: user roles, collection boundaries, metadata design, references, templates, and operating rules matter.

For regulated or high-sensitivity environments, we should discuss requirements before rollout.