Get started with Jira Service Management for admins
Your first stop for learning how to get started with Jira Service Management.
Use basic search to find specific issues. The basic search provides a user-friendly interface that lets you define complex queries, without needing to know how to use JQL (advanced searching).
If you don't have complex search criteria, try quick search instead.
If you're comfortable with the Jira Query Language (JQL), you can try the advanced search.
To use basic search:
From the navigation bar, select Filters > View all issues.
If you see JQL (advanced search), instead of basic search, select Basic.
Set your search criteria, like Project, Status, and Assignee.
Optionally, enter text to search for and add more criteria by clicking +More.
When using the search field in basic mode, results will be based on the summary, description fields, and all text fields. To search comments and worklog too, select More + to view additional field filters, then select Text.
When searching for text, you can use special characters and modifiers in your search text, such as wildcards and logical operators. See Search syntax for text fields.
What can stop you from switching between basic and advanced search?
In general, a query created using basic search will be able to be translated to JQL or advanced search, and back again. However, a query created using JQL may not be able to be translated to basic search, particularly if:
the query contains an OR operator (note you can have an IN operator and it will be translated, e.g. project in (A, B))
i.e. even though this query: (project = JRA OR project = CONF) is equivalent to this query: (project in (JRA, CONF)), only the second query will be translated.
the query contains a NOT operator
the query contains an EMPTY operator
the query contains any of the comparison operators: !=, IS, IS NOT, >, >=, <, <=
the query specifies a field and value that is related to a project (e.g. version, component, custom fields) and the project is not explicitly included in the query (e.g. fixVersion = "4.0", without the AND project=JRA). This is especially tricky with custom fields since they can be configured on a Project/Issue Type basis. The general rule of thumb is that if the query cannot be created in the basic search form, then it will not be able to be translated from advanced search to basic search.
Why can't I find the field I want to choose?
Some fields are only applicable to specific projects. If you don’t see a specific field, it could be because you don’t have browse permissions for the project that contains the field.
Why are the field criteria displayed in grey text?
Some fields are only valid for a particular project/issue type context. If you choose a field in your search, then remove all projects/issue types that reference the field, then the field is invalid. The invalid field does not apply to your search and is displayed in grey text.
Why is there a red exclamation mark in my field?
Some field values are only valid for a particular project/issue type context. For example, you may have configured a project to use a status In QA Review in its workflow. If you select this project and status in your search, then change the search to filter for a project that doesn't use In QA Review, the status will be invalid and ignored in the search.
What happens when two of my fields are named the same?
Fields in team-managed projects are contained within the project itself. So, you can create fields with the same name in different projects. Learn more about custom fields in team-managed projects.
Refining your search criteria using the duplicate field names just got easier. Pick the right criteria for your search results based on the field type that shows up along with the duplicate field names.
Was this helpful?