Developer Support


1.0 Contacting Support

2.0 Support Process

3.0 Receiving New Releases

1.0 Contacting Support

An important part of our relationship with you is responding to your technical inquiries. These can be bug reports, feature requests or simple usage questions. Please find below details on the best ways to engage with us on these technical queries. It’s generally more efficient for everyone to use our support portal but if that is proving difficult feel free to call us directly at our offices or just sending an email.

If you are on a self-guided evaluation of a Tech Soft 3D product, please submit your support questions via the Tech Soft 3D Community Forum for help. You should receive a response to your question within 3 business days. We welcome feedback in the forum from both evaluators and partners. However, the ability to request bug fixes and submit official feature requests is reserved for our commercial partners

1.1 Methods of Contact

Support Website

When you require technical assistance, we encourage you to submit the information via our Online Support Portal, located at:

https://techsoft3d.atlassian.net/servicedesk/customer/portals

If you are accessing the site for the first time click on the link, Forgot Password, and you will be sent your initial password. After logging in, select the appropriate submission form to “Report a bug”, “Ask a question” or “Suggest a new feature”.
An ID will be associated to your request and included in the subject line of related emails, and be displayed in the following format: SDHE-xxxxx Issue Summary.
SD for Service Desk, HE for HOOPS Exchange (SDHV for HOOPS Visualize, etc.) xxxxx for the issue number.
Please include the issue ID (and maintain its original formatting) in the subject of any further correspondence on the matter. You can also use the support portal to track the status of your issues, submit test files, etc.

E-Mail

The support@techsoft3d.com and eventum@techsoft3d.com email addresses have been retired.

HOOPS SDK Products

We strongly encourage you to use our new Online Support Portal to review your issues and report new ones. This will help ensure all the required information is provided which will result in quicker resolution times. You will find all of your issues from the old system have been migrated to the new portal. New email addresses are associated with the new portal and facilitate communication with Tech Soft 3D Support.
NOTE: You must have access to the new portal and log in at least once in order to effectively use these addresses.
You can send an email to one of these email aliases to automatically create an Info Request:

HOOPS Demo Viewers

To request a License key for our Demo Viewers please contact support.hv@techsoft3d.com

OEM Products

For support with the AutoCAD OEM or Inventor OEM development platforms please send an email to:

Paavo Rantanen: paavo@techsoft3d.com

If your support inquiry pertains to RealDWG, the AutoCAD API (ObjectARX) or the Inventor API then please login to your ADN (Autodesk Developer Network) account and log a support case there.
Alternatively you can log into the partner centre and create a case there.

3rd Party Support Accounts

For technical assistance please send an email to:

Tech Soft 3D Website User Access

If you have trouble accessing our Online Support Portal or Developer Zone, please send an email to support.hv@techsoft3d.com

Phone

You can also contact our support group via the following:

  • Americas (includes U.S.A.): +1.510.883.2180

  • Europe, Africa & Middle East: +33 4 72 81 68 81

  • Asia & Australia (includes Japan and South Korea): +81-(0)45-313-2555

1.2 Required Information

Before contacting our support team some of the general guidance we provide is:

A. If you want to “Ask a question”, have you:

B. If you are “Reporting a bug”you should first download the latest release from the HOOPS Developer Zone to confirm it’s still an issue. If it is still an issue then some items to consider which will help ensure quick resolution of the issue includes::

  • Do any of the available samples or demonstration programs experience the same results? If yes, which program and how is it used to demonstrate the issue?

  • Are special compiler/linker options being used?

  • Does the same result occur on multiple platforms?

  • If you cannot reproduce the problem in the sample programs or demos, it would be very helpful if you could provide the following information:

    • HOOPS Visualize: there are a couple of options here:

      • a standalone test case.

      • a piece of code which can be added to the simple apps on HOOPS Visualize:3DF or the sandbox apps on HOOPS Visualize:HPS.

      • a code snippet generated from the code-generation capabilities of HOOPS Visualize.

    • HOOPS Exchange:

      • a standalone test case.

      • a sample file which demonstrates the problem when loaded into the HOOPS Demo Viewer or the HOOPS Exchange Demo.

    • HOOPS Publish:

      • a standalone test case.

      • a sample file which demonstrates the problem when loaded into the HOOPS Demo Viewer or the HOOPS Exchange Demo.

    • HOOPS Communicator:

      • For viewer-side issues please submit an HTML and JS file(s) that reproduces the problem.

      • For conversion issues, please submit any sample files along with specific converter.exe settings and log files which enable us to reproduce the problem.

Once these questions have been considered, please contact Developer Support, who will gather necessary information and work to resolve your issue.

1.3 Uploading Files

  1. Open https://transfer.techsoft3d.com in a browser.

  2. Register for a new account using your email address.

  3. Review Create a File Link to learn how to generate file links to share with Tech Soft 3D Support.

  4. Once you have generated a file link you can copy and paste it into your support ticket.


2.0 Support Process

The following steps outline the standard process for requesting and obtaining support assistance:

  1. Use the Create Issue form to log an issue in the online support system and submit any related test programs/files. At creation time you my indicate the severity and the business impact of the issue. The severity will influence how the urgency with which the support team will respond. To ensure the system works well please use the highest level severity for only your most urgent issues.

  2. Once an issue is created it’s assigned to a support engineer who works on the issue until it is resolved. Resolution is defined as either arriving at a point where the issue can be closed (a question was answered, feedback was provided, etc…), or assigning the Bug or Feature to our Engineering team.

  3. If an issue is a Bug, it is given a status (Will Not Fix, Deferred, In Consideration, Imminent, In Development) based on its position within our development backlog.

  4. If an issue is a Feature, it is given a status (Declined, Deferred, Targeted, In Development) by our Product Management Team.

  5. When a decision is made to target the delivery of a Bug-fix or Feature in a specific release, the release value is set in the ‘Fixed Version’ field (the default value is ‘Unscheduled’.) and the status of the issue changes to 'In Development'.

2.1 Issue Category

Issue Type

Description

Info Request

A request for information about product usage, distribution, licensing, etc.

Bug

The issue is an apparent bug with our product and/or documentation.

Feature Request

A request for new functionality within the product, or a limitation which Tech Soft 3D has determined can only addressed via new functionality.

Duplicated issues are systematically declined, the older ticket will be taken into consideration.

2.2 Issue Status

Info Request

Info-request workflow

Bug

Bug workflow

Feature Request

Feature-request workflow

The following status have a standard meaning across Info Requests, Bugs and Features

Issue Status

Description

Assigned

A Support Engineer is actively working on the issue.

Backlog

The issue has been confirmed as a bug and assigned a severity 3 or 4.

Closed (Bug Created)

The issue turned out to be a bug and a new ticket has been created.

Closed (Info Request Created)

The issue turned out to be an Info Request and a new ticket has been created.

Closed (Feature Created)

The issue turned out to be a limitation and a new feature request ticket has been created.

Closed/Resolved

The Info Request, bug/feature request has been handled.

Declined/Will Not Fix:

The bug/feature has been confirmed but will not be fixed. This is because the issue is not severe enough to resolve or it has spent more than two years in the Deferred status. We realize that sometimes this will not work for our partners and so please contact Support if you need to reset the status.

Deferred

The bug/feature has been confirmed but no specific timeline has been committed to. The time frame for a decision is a maximum of 24 months.

Imminent*

We have verified we can fix the bug and it will be assigned to an upcoming development sprint. The time frame for resolution in an official release is 3 months.

In Consideration*

The bug has been confirmed and will be assigned to one of the upcoming development cycles. The time frame for resolution in an official release is usually 6 months. Applies to bugs only.

In Development

The issue is been actively worked on by our Engineering team.

In Review

The feature is being reviewed by the Product Management team.

In Test

The bug has been resolved internally and is going through internal validation. Applies to bugs only.

Needs Partner Review

The issue is awaiting customer feedback or activity. When we request more information/action on your part, we change the status of your issue to “Needs Partner Review” until you respond.

Needs Input

This status is specific to the Feature Request, our Product Manager is awaiting feedback to proceed on the request. When we request more information/action on your part, we change the status of your issue to “Needs Input” until you respond.

Open

A new issue which has not been assigned to a Support Engineer yet.

Pending Release

The fix has been validated and will be made available in the next Update or Service Pack (see Fixed Version value for more details).

QA in Progress

The feature has been assigned to our Quality Assurance team for validation. A preview might be shared with you to confirm the correct implementation of the functionality.

Refused

An issue created for a product not covered in your license agreement.

Targeted

The feature request has been validated by our Product Management team and will be assigned to our engineering team for implementation. The time-frame for delivery in an official release is ~6 months (the specific version will be detailed in the Fixed Version field).

Triage

The issue has been confirmed as a bug and assigned a severity 1 or 2.

*while we will make best efforts to address bugs in this status it is possible that on deeper investigation we determine we cannot resolve the issue.

2.3 Issue Severity

When creating an issue, you can indicate the Severity which will contribute to assess the overall internal priority of the issue. We ask you to refer to the following table to determine which severity level reflects the impact to your business:

Issue Severity

Description

1- Crash / Regression / Show Stopper

  • Stopping business and/or development operations and schedules

  • Non-functional – no workaround identified

  • Regression

2- Major Failure

  • Significantly affecting business and/or seriously impeding development operations and schedules – work proceeds but is restricted

  • Some/partial loss of functionality

3- Minor Failure

  • Somewhat affecting business and/or development operations and schedules – work continues mostly unaffected

  • Minor loss of functionality

4- Cosmetic

  • Minimally affecting business and development operations and schedules

  • No loss of functionality

If you designate an issue as having a Severity 1, we ask that you include a brief explanation as to why. This will help ensure that appropriate attention is applied to your critical business issue. Please note that severity will not necessarily map over to a specific priority.

Selecting the Correct Severity Level

When choosing the severity, please consider these questions to determine the degree to which production is stopped or impeded:

  • Is the issue preventing forward progress and production is completely stopped with no identified workaround?

  • Can some progress be made with an alternative method, but the current workaround is not sustainable and is not a long-term solution?

  • To what degree of functionality loss is being experienced – total loss in functionality, some or partial loss, minor loss, or no loss?

2.4 Business Impact

When creating an issue, you can indicate its business impact which will contribute to priority of the issue. Use the following table to determine the business impact of your issue:

Business Impact

Description

1- Customer Report / All Users

  • Issue reported by several of your customers

  • Multiple datasets/files failing

  • Affecting many users

2- Customer Report / Few Users

  • Issue reported by one of your customers

  • Some datasets/files failing

  • Affecting small number of users

3- Internal Report / All Users

  • Issue found internally by your team

  • Some datasets/files failing

  • Could affect many users

4- Internal Report / Few Users

  • Issue found internally by your team

  • Some datasets/files failing

  • Could affect small number of users

2.5 Response Time

We understand responsiveness is extremely important for our partners. Below we detail the response times we target as an organisation for each inquiry type. Please note that resolution of an issue may require several rounds of correspondence.

Issue Type

Response Time

Info Request

We target a 48 hour response time. Since bugs/feature generally require a product delivery we prioritize Info Requests over Bugs and Features.

Bug

We do a quick initial review to ensure we have all the required information to investigate the issue. We target a 4 days response time for bug confirmation. Once a bug is confirmed you will be immediately be able to get a sense of a timeline for delivery of a fix from the issue status.

Feature Request

We receive numerous feature requests, and strive to balance them against product direction and available resources. Simple feature requests are considered in the same time scale as bugs. More complex ones are reviewed during our annual product planning sessions, If you have a complex request it is encouraged that you reach out directly to the product manager.

Documentation Bugs/Features

Documentation Bugs/Features in our documentation are fixed in a similar process to bugs.

Third Party Bugs/Features

These are reported to the third party supplier with no further action by Tech Soft 3D. If something is assigned a P1 then we will encourage the Third Party to provide resolution, and notify the customer of the likelihood/timing of any resolution.


3.0 Receiving new releases

All our releases are available for download from our Developer Zone.

Release Naming and Frequency

The naming convention is HOOPS <Product> <Major> <Minor> <Update> and the frequency for our releases is:

  • 1 Major feature release per year (e.g. HE 2020).
    Our major releases go out in the December/January time-frame while .

  • 2 Service Pack releases per year (e.g. HE 2020 SP1).
    Our Service Pack 1 and Service Pack 2 releases generally go out in the March/April and August/September time-frame

  • Updates Release to our packages are unscheduled and are released as required (e.g. HE 2020 SP1 U1).