Use case

Tell customers which files work

Service desk requests come from outside your organization, where nobody knows your file policy until it stops them. Regulit puts the accepted types on the request form itself.

Book a free demo Try free on Marketplace

Shown before the upload, not after

Recorded in a live Jira Cloud site. 2 minutes, no sound.

Where it goes wrong

The rule is invisible until it rejects you.

A requester learns your policy from its consequence, and that costs a day per ticket.

Nothing on the form says anything

A customer picks a file, submits, and finds out about the policy afterwards. The upload field never warned them.

Every rejection costs a reply

An agent writes back, the customer answers two hours later, and the request has aged a day before the work starts.

Some requests never come back

Somebody whose attachment kept disappearing calls instead, or gives up. That ticket does not appear in any queue.

On the portal

The accepted types stand above the upload field.

Switch on Show file type overview to users and Regulit adds a banner to the portal, built from the rule that space runs. Change the rule and the banner changes with it.

Before the upload. The banner sits on the portal home page and the request form, where the customer reads it before attaching anything.
And afterwards. The same list appears on the request detail view, so somebody coming back to follow up sees it again.
It cannot drift. The list is the space configuration itself. There is no second place to keep up to date.

What happens when a file breaks the rule

support.example.com/portal

Summary

Description

Drag and drop files here

When it happens anyway

The requester reads why the file went.

A request that breaks the rule still gets an answer, and the answer is not a support reply written by hand.

Public where it needs to be. When the person who uploaded is not an agent, Regulit writes the comment publicly, so the customer sees it in the portal.
Named, not vague. The comment names the file and the rule that removed it, on the request where it happened.
Recorded either way. Every removal is a row in the log, with the request, the rule, the person and the time.

The Regulit log, one row per change — One row per removal, with person and time.

What the check reads

A file name is a claim. The bytes are the fact.

Uploads from outside your organization are the ones you know least about. Switch on the content check and Regulit stops trusting the name.

The extension
What the file calls itself. Easy to change, and the first thing that gets changed.
The reported type
The type Jira reports for the file.
The leading bytes
What the file actually is. A Windows program announces itself in its first two bytes, whatever the name says.

Not a virus scanner

Regulit compares these three and finds a file that is not what it claims to be. It does not inspect contents for malware, and it will not stop somebody determined to get past it. It stops habit and mistakes, which is most of what arrives.

The content check option in the Regulit app settings

Questions about the portal

Where does the notice appear?

On the portal home page, the request form and the request view. Turn it on with Show file type overview to users.

Can the portal have its own rule?

Yes. Override the file types in the service desk space. Other spaces keep the global rule.

Does the customer see why the file went?

Yes. When a customer uploads, the comment is public. With popup notifications on, they also get a short message.

Can agents approve held files?

Yes, if Service desk agents may approve or reject is switched on.

Does it scan for viruses?

No. It checks file types and file signatures, not malware.

Read on

Two pages carry the rest.

This page argues the case for showing the rule on the portal. What the app does with an upload, and what it takes to switch it on, each have a page of their own.