# Welcome to Opser One system for your business: apps your team uses, agents that do the work, and the context they share. Source: https://docs.opser.com/ ## Apps, agents, and shared context Opser brings the software your business runs on and the agents doing the work into one workspace. Your team uses apps to manage records and workflows. Agents work inside those apps, use connected services, and create the files or software you need. Business context helps them understand what the work means. These three parts fit together: | Foundation | What it gives you | | --- | --- | | [Apps](https://docs.opser.com/apps/overview/) | Interfaces, records, and business rules that people and agents can use together | | [Agents](https://docs.opser.com/agents/overview/) | AI coworkers for you or your whole team that use tools, run code, and carry tasks through to a result | | [Context](https://docs.opser.com/agents/context/) | Company knowledge, role instructions, preferences, and memory that guide the work | ## Give your agent work to do Ask for an outcome: compare a set of offers, prepare a report, investigate records, or build a workflow your team needs. Supply the relevant files or point to the source app. The agent can choose tools, ask a question, run supporting code, and return a result you can inspect. Each agent has a [persistent filesystem](https://docs.opser.com/agents/files/), and one ongoing chat that never resets, shared by everyone who can use it. Source files, scripts, and saved artifacts stay available for later work, and the agent can look back through the chat when you mention something from before. Start with [your first task](https://docs.opser.com/start/quickstart/), then explore [what Opser can do](https://docs.opser.com/capabilities/overview/). ## Shape the system around your business Use the apps available to your workspace, or describe an app you need the agent to build. Apps can expose tools and skills for agents, operations for other apps, and events that connect workflows. The connections and access rules are explicit; shared context does not make every record visible to everyone. Learn [how apps work together](https://docs.opser.com/apps/connected/) and how to [build and review an app](https://docs.opser.com/capabilities/internal-apps/). ## Set up your workspace [Open or join your workspace](https://docs.opser.com/start/access/), add business context, and give [teammates](https://docs.opser.com/workspace/users/) the right [access](https://docs.opser.com/workspace/permissions/). Then adjust your [preferences](https://docs.opser.com/workspace/preferences/) and understand [usage and credits](https://docs.opser.com/billing/usage/). You can read these docs without signing in. Each guide also has **Copy page** and **Markdown** controls for using its full text with an agent. --- # Your first task Give your agent a real task, follow its work, and keep a result you can use. Source: https://docs.opser.com/start/quickstart/ ## Start with your agent [Open your workspace](https://docs.opser.com/start/access/) and choose **Agent** in the sidebar. This is the default agent created with your account. It never does more than you could, keeps its own persistent files, and follows the instructions you give it. You can start with a file and a task before connecting an external service or building an app. If the workspace is new, you can first tell the agent what your business does. It can help capture company context and your role. You can also go straight to work and refine that context later. ## Give it a specific outcome Describe the source, the result, and any boundary that matters. For a first task, use a file whose contents you know so you can judge the result. > Use the attached spreadsheet to prepare a weekly operations summary. Group the work by owner, flag missing deadlines, and create a one-page report. Save the report and the script used to calculate the totals. Do not change the source file. If the information lives in an app or connected account, identify it. The agent needs access to that source; describing a system does not connect it. ## Follow the work The chat shows what the agent writes, its questions, and the files it makes; while it works, a line beside its avatar says what it is doing. The agent can read the attachment, use a document or spreadsheet tool, and [write and run code](https://docs.opser.com/capabilities/code/) when the task calls for it. It can keep the source, script, and result in its [workspace files](https://docs.opser.com/agents/files/). To see each action and its result, turn on **Show the agent's steps** in **Settings → General**. If the agent asks a question, give it the missing detail. You can also send a correction while it works: it reads it after its current step. If an action needs approval, review the target and proposed change before accepting. [Approvals](https://docs.opser.com/agents/approvals/) and [access permissions](https://docs.opser.com/workspace/permissions/) serve different purposes. ## Check and refine the result Open the generated file or resulting record. Check the values, the source, and whether the output answers your request. Reply in the chat to refine it: > Put the three oldest items first, keep the report under one page, and explain any rows excluded from the totals. A file saved in the agent workspace can be reused later. If the result needs to be a shared business record, ask the agent to store it in the appropriate app or storage location and confirm the sharing. A chat attachment and a team record are different things. ## Make the next task easier Save durable company information in [Context](https://docs.opser.com/agents/context/), and use a [skill](https://docs.opser.com/agents/skills/) for a process you repeat. Give the next task in the same chat. It never resets: the agent keeps its workspace and settings, and it can look back at earlier work when you mention it. Once a task works reliably, ask about a [schedule](https://docs.opser.com/agents/automations/). If the work needs a dedicated interface, describe the workflow and [build an app](https://docs.opser.com/capabilities/internal-apps/). You can keep using the chat and apps together. --- # Open your workspace Create a workspace or join your team, sign in, and find your agent. Source: https://docs.opser.com/start/access/ ## Open your team's workspace Each Opser workspace has its own address. To find yours, open [Log in on the Opser website](https://opser.com/login), verify your email with the code sent to your inbox, and choose a workspace. You will then sign in on that workspace’s own login page. Verification on the website only reveals your workspace links; it does not sign you in. Use the link provided when your organization was set up, or ask your administrator for it. These public docs are separate from your private workspace and do not sign you in. If you are joining a team, ask an administrator to [add your account](https://docs.opser.com/workspace/users/) and provide the workspace link. A new workspace is a separate environment, so do not create one when you intend to join the existing team. ## Sign in and verify your email **Sign in · Fictional data** Maya signs in to the fictional Northstar workspace with maya@northstar.example and a password. These fields are an illustration. Sign in with your account email and password. When prompted, enter the verification code sent to that email address. The sign-in flow shows the verification step; keep the code private and use it there. If the code expires, start a fresh sign-in and use the new code. If the message does not arrive, check the email address and spam folder. Ask your administrator for help if verification email cannot be delivered. Invited to a workspace? Open the link in your invitation email, enter your name and choose a password. You're signed in straight away. ## Start a new workspace Use the [Opser signup page](https://opser.com/signup) to begin setup. Review the workspace and plan details shown there. For help choosing a setup, [contact Opser](https://opser.com/contact). Once you are inside, tell your agent about your business or [give it a first task](https://docs.opser.com/start/quickstart/). Add stable company information in [Context](https://docs.opser.com/agents/context/) so future work has a useful starting point. ## Recover access If you have forgotten your password, choose **Forgot password** on your workspace's sign-in page. Enter your account email, open the reset link from the email, and choose a new password. A reset link is for one use; request a new one if it is invalid or expired. Use the correct workspace address for recovery. If you still cannot sign in, ask your administrator to check your account and include the visible error in a support request. Do not send passwords, verification codes, or reset links to an agent or support conversation. --- # What is an agent? An AI coworker with its own instructions, tools, memory, and persistent workspace. Source: https://docs.opser.com/agents/overview/ ## An agent has a place to work An Opser agent is an AI coworker that can take actions to complete a task. It combines a language model with instructions, tools, memory, and a persistent filesystem. It can investigate information, write and run code, work with business records, create documents, and build apps when those capabilities are enabled. **An agent conversation · Fictional data** The chat header shows the agent’s avatar — a friendly sky-blue character — and its name. The agent inspects available data and saves a customer portal plan as portal-plan.md in its persistent workspace. The model handles reasoning and language. The surrounding Opser runtime supplies the workspace and the actions it can take. Switching models does not turn a different conversation into the same thing as a different agent. ## What an agent carries between tasks | Foundation | How it is used | | --- | --- | | Identity and instructions | Its name, behavior, role knowledge, and standing guidance | | Business and personal context | Information about your organization and the people it serves | | Memory | Facts the agent can save and retrieve for future work | | Persistent files | Source files, scripts, notes, and results kept in that agent's workspace | | Tools | Actions for reading, calculating, updating, building, and communicating | | Skills | Instructions for carrying out a kind of work with those tools | | Connections and access | The external accounts, apps, and records it is authorized to use | Each agent has one ongoing chat, shared by everyone who can use it, and it never resets. When it gets long, the agent keeps a summary of earlier messages and looks up exact details in the chat when it needs them; its saved files and configured context stay as they are. ## From a request to a result An agent can break a task into steps, inspect inputs, choose tools, ask for a missing detail, run a script, and review the output. Some actions require approval. The chat shows what the agent writes and makes, with a short line saying what it is doing while it works; turn on its steps when you want to inspect each action. See [what you see while the agent works](https://docs.opser.com/agents/conversations/#what-you-see-while-the-agent-works). For example, an agent can read several source files, calculate a comparison, save a reusable script, and produce a report. If the result belongs in an installed app, it can use that app's supported tools to create or update the record. Read [Built-in tools](https://docs.opser.com/agents/tools/) and [Code & scripts](https://docs.opser.com/capabilities/code/). ## Your agents You start with a default agent and can create additional agents for different kinds of work, such as a product manager, researcher, or blog writer. Each agent has its own workspace, configuration, and connections, and an owner, who controls its settings. On a specialist agent, the people with access can also teach it what to know and how to act (see [Context & memory](https://docs.opser.com/agents/context/)). Every [plan](https://docs.opser.com/billing/plans/) lets you create as many agents as you need. An agent does not gain access to another person's private files or an unconnected service just because you mention them. Ask it to identify the missing source or permission when it cannot complete a task. ## Give people access Any agent can be given to other people, including the default agent you start with. Its owner or an admin opens **Access** in the agent's settings and chooses **Add people**, or asks the agent in its chat, which asks for approval before giving or removing access. Access lists everyone who can use the agent, starting with its owner. An agent can serve a team around a process such as coordinating requests or preparing operational reports. Everyone with access uses the agent together: one chat that everyone sees and writes in, where each message shows who wrote it, plus the agent's automations and their results, its files, its memory, and the accounts it is connected to. Connections belong to the agent, not to the person who made them. Each person keeps their own unread state. When anyone besides its owner can use an agent, the faces of the people with access show at the top right of the chat, just before the search button, on the chat page and in the side chat. Select them to see who has access; its owner or an admin also sees **Manage access** there, which opens **Access**. When someone gets access, a line in the chat says so where it happened: they can see the whole chat, earlier messages too. An agent never does more than its owner could, and never more than the person talking to it may do in Opser. Giving people access is not a shortcut around record permissions. Before you add someone, review what the agent's chat, files, and memory already hold and which accounts it is connected to: that person will be able to see and use them. Open **Settings → Agents** to manage the agents available to you. Creating agents requires permission. Giving other people access to an agent is included on every plan, Free included. ## Delegated work For a longer task, the main agent can delegate a bounded part of the work to a subagent and bring its report back into the conversation. A subagent receives a task brief and selected tools; it is not another permanent agent you need to configure. Delegation does not expand authority. Subagents cannot ask you questions or complete approval-gated actions themselves. The main conversation handles those decisions and brings the results together. ## Recognize your agents Every agent has a saved identity: a name and an avatar built from a shape and a color, with an expressive face. Your default agent starts as “Agent” with a randomly assigned avatar; when creating another agent, you can give it a role-specific identity. The **General** settings let you rename it and pick another look. Everyone who can use an agent sees the same identity. **Your agents · Fictional data** Three agents, each with its own avatar: the Opser agent, used only by its owner, as a sky-blue rounded character; a Support agent four people use, as an apricot flower shape; and a Reports agent two people use, as a mint star shape. The workspace sidebar lists the agents available to you above Apps, each with its avatar, name, and unread activity. Choose one to open its chat; an empty chat greets you with that agent's avatar, and chat headers show the avatar beside the name. Avatar motion follows your reduced-motion preference. ## Configure and use the agent The chat's header has a search button and a gear. The gear opens the agent's settings in a panel beside the chat, so you never leave it. It shows the agent, then its sections, each with its icon: **General**, **Plugins**, **Approvals**, **Automations**, **Files**, and **Access**. An open section shows a back arrow, its icon and its name, then a line saying what it is for; the arrow goes one level up. Drag the panel's edge to resize it and close it with **×**; on a phone it opens as a sheet. The agent can change most of these settings itself when you ask in the chat. The controls available depend on your access. Continue with [your chat with an agent](https://docs.opser.com/agents/conversations/), [context and memory](https://docs.opser.com/agents/context/), or [persistent files](https://docs.opser.com/agents/files/). --- # Your chat with an agent Keep working in one chat with each agent, follow what it is doing, find earlier messages and files, and make your requests easier to act on. Source: https://docs.opser.com/agents/conversations/ ## One chat with each agent Each agent has one ongoing chat. Open the agent from the sidebar and write: there is no list of chats to manage. On other pages, the agent at the top right opens its chat beside the page. Messages, the agent's replies, and the results of its automations stay in that one chat, so you can pick up where you left off. When other people have access to the agent, they use the same chat: everyone sees it and writes in it, and each message shows who wrote it. Each person has their own unread state, so a message you have read can still be new to a teammate. See [Give people access](https://docs.opser.com/agents/overview/#give-people-access). The chat never resets. When it gets long, the agent compacts it: it keeps a summary of the earlier messages (people, decisions, preferences, work done, open questions) and the latest ones word for word, and a **Chat compacted** card marks where it happened; choose **Show summary** to read what it kept. Nothing is deleted. You can scroll back and search everything, and so can the agent: ask about something from weeks ago, a decision or a file, and it looks it up in the chat. ## What you see while the agent works The chat reads like messaging a teammate: your messages and the agent's appear as chat bubbles. While the agent works, a row at the bottom of its reply shows its moving avatar and a short line saying what it is doing, such as the step it is on or **Working…**, with the time taken once the work runs long. While an approval waits for you, the line reads **Waiting for your approval**. The tools the agent uses, its reasoning, and the other steps behind each reply are hidden. What needs you, or what the agent made, still shows: an approval request waiting above the composer, the agent's questions, cards to connect an account, the files it made, a notice when you run out of credits or a connected ChatGPT plan reaches its limit, the live browser while the agent uses it, and the **Chat compacted** card. A reply that ended with nothing to show reads **Finished without a reply**, and one that was stopped reads **Stopped**. To see the steps, turn on **Show the agent's steps** in **Settings → General**, or ask the agent to turn it on for you. The chat then also shows the tools behind each reply, the agent's reasoning, and its plan and sub-agents, with its messages still in bubbles. The setting is yours alone: it does not change what a teammate sees in a shared chat. A reply describing an action is not proof that the action has finished; check the resulting record, or turn on the steps to read the tool result. ## Send while it works You don't have to wait for a reply. Write while the agent works, and your message shows at the bottom of the chat, marked **Read after the current step**. The agent doesn't stop: it reads your message once the step it is on ends and carries on with it in mind, and what it says next appears below your message. Several messages sent during one step reach it together. While the agent works, the button beside the input is the stop button; on a computer, press Enter to send. In a shared chat, a message a teammate sends while the agent works on someone else's request waits until that work ends, and then gets its own reply. ## Write a useful brief Include four things when they matter: **A question from your agent · Fictional data** Next to its avatar, the agent asks who will use the portal. Customers is selected; partners and the team are other options. 1. **Outcome:** what you want at the end. 2. **Source:** which app, records, file, or connection to use. 3. **Constraints:** deadlines, audience, format, and changes to avoid. 4. **Review point:** what you want to approve before the agent continues. > Use the attached supplier offers to create a comparison by unit price, minimum order, and lead time. Keep currencies separate. Show the comparison before creating any purchase orders. Answer clarification questions directly. If the agent chooses the wrong record, identify the correct one using its name and another distinguishing detail. ## The agent learns as you go Tell the agent about its job while you work: its role, who it writes for, how to write, rules to follow. It saves what is meant to last to its own description, personality and knowledge, which you can see and edit in its settings, and says so in a short line. When you ask for something that repeats, such as a summary every Wednesday, it sets up an automation for you to approve. When you describe a long, step-by-step way of doing one job, it proposes a [skill](https://docs.opser.com/agents/skills/) for you to approve instead of adding the steps to its knowledge. One-off requests stay one-off. On a specialist agent other people use, everyone with access can change its personality, knowledge, rules, skills and automations, unless its owner turned that off; only its owner or an admin changes the rest. ## Find earlier work Use the search button in the chat's header, or press ⌘F (Ctrl+F on Windows and Linux). Before you type, it lists the messages people sent, newest first, so you can jump back to any of them. Type to find words in messages, the agent's replies, and file names across the whole chat; more results load as you scroll. Choose a result to scroll the chat to it. On a wide screen, a line of short marks beside the chat stands for the messages people sent around where you are, however far back. Point at a mark to read the message and click it to go there. Open the gear in the header and choose **Files** to see every file in the chat: what you uploaded and what the agent made. Keep durable facts in [Context](https://docs.opser.com/agents/context/) or a shared knowledge app as appropriate; do not rely on a long chat as the only record of a business decision. ## Files and interruptions Attach relevant files to the request. The agent keeps its working files in its [workspace](https://docs.opser.com/agents/files/). Use the stop button when the task needs to change. Stopping does not undo actions that already completed, and messages the agent has not read yet are answered next. For a small change, you often don't need to stop: send it, and the agent picks it up after its current step. For unexpected failures, check approvals, access, and connections before retrying a write. See [troubleshooting](https://docs.opser.com/help/troubleshooting/) for a checklist that avoids duplicate changes. ## Talk instead of typing When the input is empty, choose the voice waveform button to talk with your agent about CRM records, deals, tasks, or other connected apps. Your speech and the agent’s reply appear in the conversation like any other message. Voice stays connected as you navigate. Before your first call, review the credit rate; live audio uses workspace credits even with a connected ChatGPT subscription. See [Voice conversations](https://docs.opser.com/agents/voice/) for controls, voice previews, billing, and microphone access. --- # Voice conversations Talk with your Opser agent, choose a voice, and understand live voice credits. Source: https://docs.opser.com/agents/voice/ ## Talk with your agent In an empty chat input, choose the voice waveform button to start a live conversation. When you type or attach a file, that position becomes Send. The separate microphone button dictates an editable text draft instead. Allow microphone access when your browser asks. On first use, review the credit rate and choose **Start with credits**. You can ask about your CRM, deals, tasks, or other apps the selected agent can access. Results appear in the same chat, and a pending approval waits above the composer. The agent asks follow-up questions aloud. When an action needs approval, it describes the action and asks you to say **approve** or **reject**; an unclear or qualified response does not run the action. Your words and the spoken reply appear progressively as messages in the chat. The compact card above the input shows your agent’s avatar, which reacts to your microphone as you speak and animates while the agent talks, plus a mute control. It respects reduced-motion preferences. The voice button becomes an **X** to end the conversation. Pricing appears before your first call, keeping the call controls focused on the conversation. Within each voice reply, the agent's detailed results appear before the spoken transcript, along with its tool activity when **Show the agent's steps** is on. Files, approvals, errors, and results that arrive after you end voice remain available. The transcript stays in the chat after the call settles. ## Control your conversation Use the microphone control to mute yourself and **End voice** to stop the call. Muting does not stop credit usage. Interrupting spoken audio does not cancel an action already running: use the chat’s Stop control when you want to cancel agent work. Ending voice leaves authorized work in chat. Voice stays connected while you navigate within Opser. On desktop, a working conversation follows you into the agent sidebar; on mobile, compact controls let you mute or end voice while viewing an app. Idle conversations do not open automatically. A call has no set length: it ends by itself after 10 minutes without anyone speaking. Closing the tab, signing out, losing the connection, or running out of credits also ends it. Reconnecting requires a new call; actions are not replayed automatically. ## Keyboard shortcuts Focus the chat and use **Ctrl+D** to start or stop dictation (Control on Mac too), or **Ctrl+Shift+Space** to start or end live voice (**Cmd+Shift+Space** on Mac). The shortcuts appear in each button’s tooltip and follow the same controls: voice starts when the input is empty, the first-use credit notice still appears, and disabled controls stay disabled. If two chat panels are open, focus the one you want to use. While you dictate, press **Enter** to send what you said; **Ctrl+D** or the pencil puts it in the message box to edit first. Dictation already knows your teammates, agents, apps, and company; to teach it other words or fix one it keeps getting wrong, see [Teach dictation your words](https://docs.opser.com/workspace/preferences/#teach-dictation-your-words). ## Choose your voice GPT Live speaks with your selected Opser agent's name and personality. Voice tool work uses GPT-5.6 Luna with low reasoning, with workspace and dynamic app tools available. Question forms and connection cards stay in text chat because they require on-screen interaction. Text chat keeps its configured model and reasoning. If your agent uses a connected Codex subscription, voice tool work uses Luna through that subscription; otherwise it uses the metered OpenAI API. Live audio is always billed separately in credits. Open the agent’s **General** settings and pick a voice under **Agent voice**. Each agent keeps its own voice, and a call uses the selected agent’s voice. Play the preview beside any voice to hear a short sample without spending workspace credits. Changes apply to your next call. Its owner or an admin can also ask the agent to change it. ## Understand credits The first-use notice shows your workspace’s current credit rate for live voice. Live voice is billed per second, with a 15-second minimum when connecting. Silence, muted time, and waiting for the agent count while the session is open. Opser reserves a short amount of credit ahead of use. Unused reserved credits are returned when the call is settled. If a connection fails before final usage arrives, Opser retains the confirmed usage it received and marks the final amount as unconfirmed for billing review. The agent’s model and tools are charged separately at their usual rates. Live voice and dictation use workspace credits even when your agent’s text model uses your connected ChatGPT subscription. Dictation is billed by the recording’s duration, at its own rate. Open **Settings → Usage** to see voice and dictation alongside other model usage and inspect the credit ledger for reservations and refunds. See [Credits and usage](https://docs.opser.com/billing/usage/). ## Audio and access OpenAI processes the audio. Opser retains text transcripts, not audio recordings. Voice uses the selected agent’s existing access and approval policies. Spoken approval resolves only an explicit **approve** or **reject** response; a pending approval shows above the composer, and decided ones stay in the chat when **Show the agent's steps** is on. If voice cannot connect, check browser microphone permission and your workspace’s credit balance. Use a browser with WebRTC support; voice availability in an embedded mobile browser depends on its microphone support. --- # Context & memory Give your agent the background it needs without repeating your entire business story. Source: https://docs.opser.com/agents/context/ ## Add context intentionally Open **Settings → Context**. Personal context helps your agent understand your role, preferences, and responsibilities. Organization context describes the business and is managed by administrators. Good context is stable and useful across tasks: what your company does, who you serve, the terminology you use, and how you prefer to work. Keep changing records such as orders and task status in their apps. > I coordinate purchasing. Present supplier comparisons in a table, keep quoted currencies unchanged, and call out missing lead times before recommending a supplier. ## Personal and organization information Your own context is available in the personal part of the page. Organization sections may be hidden if you are not an administrator. Check which section you are editing before saving: a personal preference and a company-wide instruction have different audiences. ## Role knowledge, personality, and files The agent's **General** settings separate how it behaves from what it should know about its role. Use personality for tone and behavior, and knowledge for domain facts or standing instructions. Company-wide information belongs in organization context; a single task's requirements belong in your request. The agent also fills these in as you tell it about its job in the chat, and says so in a short line; check and edit what it saved in **General**. Saved [workspace files](https://docs.opser.com/agents/files/) and memory are also different. A file holds concrete source material or an artifact. Memory holds retrievable facts. Your chat is a third record: the agent works from a summary of earlier messages plus the latest ones, and looks up exact wording, dates, or files from further back when you mention them. Point the agent to the relevant source when exact details matter. ## Workspace timezone Agents use the workspace timezone selected during setup or in organization settings to interpret “today,” “tomorrow,” and times without an explicit timezone. Each new request receives a fresh reference time and the saved workspace timezone, including in your ongoing chat. Specify another timezone in your request when needed. Work already in progress keeps its original date reference, including delegated tasks and approval resumes. New recurring schedules save their resolved timezone; changing the workspace timezone does not move existing schedules. ## Agent rules Rules are short instructions an agent follows on every message, such as payment terms for a customer or something it must never do. When you correct the agent in a chat or tell it how something must always be done, it saves a rule and says so in one short line. Find them under **Rules** in the agent's settings, where you can add, reword, or remove any of them. A number beside **Rules** shows suggestions waiting for your approval. On a specialist agent other people use, everyone with access can shape how it works: its personality, knowledge, rules, skills and automations, from its chat or its settings. Everything else about the agent (its access, approvals, model, name and look) stays with its owner and administrators, and its members don't see those settings at all; the owner sees them marked **Owner only**. The owner can turn members' editing off under **Access**; from then on a member's correction is saved as a suggestion that applies once the owner or an administrator approves it. On someone's first agent, which acts with that person's authority, only its owner or an administrator changes anything. The agent only saves what people tell it directly, never instructions found in an email, document, or web page. ## Agent memory Agents can save and retrieve useful facts through their memory capability. Ask the agent what it remembers about a topic, tell it when a fact is out of date, and ask it to correct or forget that fact. Memory is useful background, but important policies and business decisions should also have an authoritative home, such as a shared document in an [installed app](https://docs.opser.com/apps/overview/). Point the agent to that source when asking it to apply the policy. ## Keep context useful Review it as responsibilities change. Remove contradictory instructions, outdated process descriptions, and details the agent no longer needs. For one-off task constraints, put them in the conversation instead. If the agent uses the wrong assumption, identify the incorrect fact and the correct source. After a major change, say in the chat what changed and which earlier details no longer apply: the chat keeps its history, so the agent needs to know what to set aside. Update context or the agent's settings wherever the old version is saved. --- # Built-in tools The actions an agent can take, from reading files to running code and working across apps. Source: https://docs.opser.com/agents/tools/ ## Tools turn a request into an action A tool gives the agent an operation it can actually execute. It has a name, structured inputs, and a result. Reading a spreadsheet, running a script, creating a record, and inspecting a connected calendar are tool actions. The conversation lets you follow that work. You can ask in ordinary language. You do not need to remember tool names. They are listed below so you can understand the platform's foundations and recognize them in activity details. ## Files, code, and research | Tool | What it enables | | --- | --- | | `file` | Read and write workspace files, inspect images, and return a file in the conversation | | `shell` | Run commands and scripts in the agent's working environment | | `storage` | Store files beyond a working copy, fetch them, and create supported sharing links | | `web` | Search and retrieve public web information | | `browser` | Inspect and interact with web pages through the supported browser service | The filesystem makes multi-step work possible: a tool can create a file that another tool reads. A script can process a source file and save a result for later work. See [persistent files](https://docs.opser.com/agents/files/) and [code execution](https://docs.opser.com/capabilities/code/). ## Documents and generated outputs | Tool | What it enables | | --- | --- | | `pdf` | Read, fill, merge, and split PDFs, and create a PDF by printing a document written as HTML | | `spreadsheet` | Inspect spreadsheet and CSV files: list sheets, describe them, and read rows | | `presentation` | Inspect, preview, and export presentation decks | | `media` | Generate supported images, video, and audio | The agent builds workbooks, decks, and reports by writing short programs in its sandbox, which gives it real formatting, formulas, and charts, then uses these tools to check, preview, and convert the result. These tools can work with the same workspace files. The available operations and providers determine which formats and generation options can be used. Model work and some operations consume credits; “built in” does not mean every task is free. ## Business work and platform controls | Tool | What it enables | | --- | --- | | `data` | Manage user-owned business datasets, inspect their structure, and run supported reporting queries | | `internal_app` | Build, test, review, and install a workspace app when the builder is enabled | | `external_app` | Build and publish a separate website or web app with explicit data capabilities | | `platform` | Inspect or change supported profile, context, agent, access, and workspace settings | | `notify` | Send a supported notification to a person | Platform administration uses the caller's permissions. Giving the agent a natural-language instruction does not make it an administrator. Apps contribute their own tools for the records they own — for example, the Dashboard app lets the agent inspect and arrange dashboard widgets; use those interfaces rather than treating every app table as a general dataset. ## Memory, guidance, and coordination | Tool | What it enables | | --- | --- | | `memory` | Save, find, and remove remembered facts | | `skills` | Discover and load reusable instructions, and manage supported custom or installed skills | | `plan` | Track the steps of the task in the conversation | | `ask_user_question` | Ask for a decision or missing detail | | `subagent` | Delegate a bounded task and bring back its report | | `cron` | Create, inspect, run, or remove scheduled work | | `activity` | Look up what people and agents did in the workspace | | `connector` | Discover and invoke supported operations on connected services, and start a connection for you to complete | Tools can be added to a conversation's available set when needed. The `toolbox` activation step loads a deferred tool or app toolkit; it does not execute the business action or grant new access. ## What is available to your agent Opser provides the platform tool foundation. The actual set depends on agent restrictions, workspace configuration, installed apps, connected accounts, and the task context. Some tools are scoped to a conversation or automation. App building and provider-backed services can be unavailable in an environment even though the platform supports them. A [skill](https://docs.opser.com/agents/skills/) tells the agent how to use a capability. It does not install missing software or authorize an account. When work is blocked, ask the agent to identify the unavailable tool, permission, connection, or service, then resolve that dependency. --- # Built-in skills The instructions that help agents use Opser well, plus skills you add for your own workflows. Source: https://docs.opser.com/agents/skills/ ## Instructions for doing the work well A skill is a reusable set of instructions for a kind of task. It explains when to use it, what information to gather, the process to follow, and how to check the result. A tool performs an action; a skill helps the agent choose and use those actions. Opser gives the agent descriptions of available skills so it can choose relevant guidance, then load the full instructions as needed. You can also ask it to use a particular skill. This keeps a task focused without requiring every instruction to be repeated in every message. ## The built-in foundations These skills describe how to use the core platform. They are separate from the optional catalog and your own business procedures. **Skills · Fictional data** Three built-in foundations: Data Management, Internal App Builder, and External App Builder. These teach workflows; they do not grant permissions. | Foundation | What it teaches the agent | | --- | --- | | Data Management | Inspect and structure user-managed business data, import records, and respect data boundaries | | Data Reporting | Turn business questions into useful queries and reports | | Internal App Builder | Design, build, test, and review an app inside the workspace | | External App Builder | Build a separate web experience with declared data access and deployment steps | | Scheduling | Set up recurring or one-time work and check its timing and execution | | Memory | Save useful facts, retrieve relevant background, and remove outdated information | | Integrations | Discover connected services and choose supported operations and accounts | The instructions do not remove a capability's prerequisites. For example, the app-building skill can explain the workflow even when building has not been enabled in that environment. ## Add your business's way of working Create a custom skill for a process you expect to repeat. Give it a clear name and describe the trigger, required inputs, steps, output, and checks. Test it with a representative example before making it part of routine work. > For a weekly operations review, use the supplied date range, summarize open work by owner, identify stalled items, and end with an action list. Keep currencies separate and link each finding to its source. The agent can also write one for you. When someone who may change it describes a long, step-by-step way of doing one job in the chat, the agent proposes a skill through an approval card instead of adding the steps to its knowledge, which stays short. Choose the right scope. Skills can be available to an agent, shared through the business library, or required across the workspace when configured by an authorized user. Changes to shared instructions affect more than your current conversation. ## App skills and optional installations Installed apps can contribute guidance for their own records and workflows. The platform can make those skills available alongside the app's tools, subject to access. In the agent's settings, open **Plugins** and choose the **Skills** tab. It lists the agent's skills, and **New skill** under the tab's description creates one of your own. There is no catalog to browse: ask the agent for an optional skill, and it can find one in the catalog and install it after you approve. Catalog entries evolve, so ask the agent what is available rather than treating a list in the docs as a fixed product inventory. Inspect the instructions and choose the agent or workspace scope deliberately. ## Keep the boundaries clear A skill does not grant access, connect an account, or install an app by describing it. Its tools still require the right permissions, configuration, and any applicable approval. If a skill references an unavailable operation, resolve that dependency instead of assuming the instructions made it available. Use [context](https://docs.opser.com/agents/context/) for stable facts, a skill for a repeatable procedure, and the conversation for the task at hand. See [Built-in tools](https://docs.opser.com/agents/tools/) for the execution layer. --- # Approvals & control Review proposed actions and choose where the agent should pause for your decision. Source: https://docs.opser.com/agents/approvals/ ## Review an approval request Some actions pause and wait for you before they run. The approval card above the composer says what the agent wants to do and what it is about; open it for a preview of the details. Read the target and the values — recipients, amounts, dates, and anything with an outside or irreversible effect — before you decide. **Review an action · Fictional data** Maya’s Gmail account proposes an email to alex@northstar.example about reviewing the portal. Allow, deny, request an edit, or allow future actions for that account. The card gives you four choices: | Choice | What it does | | --- | --- | | **Allow** | Run this action once, as shown. | | **Deny** | Skip this action. Tell the agent what to change; it can propose a corrected action. | | **Request edit** | Send the action back with a change instead of a flat refusal. For an outgoing email you can edit the subject and body inline before it sends. | | **Always allow this** (in the menu beside **Allow**) | Run it now and stop asking for this kind of action. For a connector, **Always allow for {account}** limits that standing permission to one connected account, so approving a send from one mailbox never auto-sends from another. | A denied or edited action does not undo work that already finished. If a later request is rejected, an earlier completed action stays done — check the affected record rather than assuming a reject rolled everything back. While a request is waiting, the chat is paused and the agent's working line reads **Waiting for your approval**. The pending card sits just above the composer, including one that a run of the agent's automations is waiting on. Allow or deny it to let the agent continue. Once you decide, the card goes away; with **Show the agent's steps** turned on in **Settings → General**, the decision stays in the chat among the agent's steps. A request left unanswered expires after 24 hours. ## Decide what needs approval Every action has a risk category, and that category sets whether it runs on its own or asks first: **Approvals · Fictional data** This example allows reading files and asks before sending email or deleting a file. Actual defaults vary by tool. | Risk category | Typical default | Examples | | --- | --- | --- | | **Read-only** | Runs without asking | Searching records, reading a file, listing calendar events | | **Mutating** | Varies by tool | Creating or updating a record | | **Destructive** | Asks first | Deleting records, removing fields | | **External** | Asks first | Sending email, posting to a connected service | | **Admin** | Asks first | Changing settings, users, or permissions | Open the agent's **Approvals** settings to see the catalog of tools and their individual actions. For each one you can set **Always allow** or **Always ask**, reset an action to its default, or apply a choice to a whole risk group. Sensitive actions have a deliberate default — for example, creating or installing a skill asks first, because a saved skill becomes standing instructions for later work. Its owner or an admin can also ask the agent in its chat to change what it asks about; each change waits for approval. A good setup lets routine reads run freely and keeps a review point on changes that leave the workspace or cannot be undone. The right balance depends on how much responsibility you have given that agent. ## Run without pausing using auto mode Each agent's chat has a permission menu next to the model picker. **Always ask** follows the approval rules above, so actions that need approval wait for you. **Auto mode** runs approval-gated actions in that chat without stopping to ask — useful once you trust a routine and want it to finish end to end. Switch back to **Always ask** to return to reviewing each request. The chat keeps the choice until someone with access changes it, and the first time you open another agent's chat it starts with the mode you last picked. Auto mode still respects the agent's permissions and never grants access it does not already have. New [automations](https://docs.opser.com/agents/automations/) created through setup or the agent run automatically by default. Creating one pre-approves the actions described in its task, including app and integration actions. They use existing permissions and accounts; your chat's Auto mode does not change an older automation's saved authorization. ## Permissions still apply Approval is consent to one particular action. Permission decides whether the agent may perform that kind of action at all. Approving a request cannot grant access to a restricted app, mailbox, or record. An agent never does more than its owner could, and never more than the person talking to it may do in Opser. When several people use an agent, the access of the person who sent the request matters too. See [permissions and access groups](https://docs.opser.com/workspace/permissions/). ## When work appears stuck Check the agent's chat for a request waiting above the composer. In **Automations**, a waiting run in the **History** list shows **Needs approval**. If nothing is pending, ask the agent what stopped it, or turn on **Show the agent's steps** in **Settings → General** and look at the most recent tool result for an error. A disconnected account, a denied permission, or an [empty credit balance](https://docs.opser.com/billing/usage/) each needs a different fix. Do not resend the same write while an earlier request is still pending. After a connection interruption, check the target record before retrying so you do not create the same thing twice. --- # Models & agent settings Choose how your agent reasons and manage a supported model account connection. Source: https://docs.opser.com/agents/models/ ## Open the agent's General settings Select your agent, then open **General**. The model list shows the models available in your environment, grouped so you can weigh capability against cost. Availability can change with your workspace configuration and any connected model account. **Choose a model · Fictional data** Advanced is selected from the Basic, Advanced, and Expert profiles. Custom opens the available models and supported thinking levels. ## Choose a model for the task Models come from several providers — the Claude, GPT, and Gemini families, alongside other supported options — and are organized into three cost tiers: | Tier | Best for | | --- | --- | | **Premium** | The most demanding reasoning: complex analysis, app building, and multi-step work where quality matters most. | | **Standard** | Everyday work that still needs solid reasoning, at a lower cost per task. | | **Budget** | High-volume or routine work such as short summaries and quick lookups. | Each model also carries a capability label — **Basic**, **Advanced**, or **Frontier** — shown next to its name. This is separate from the cost tier, so you can spot a capable model that is still inexpensive to run. Pick the model in the selector, or open **Custom** to choose a specific model and thinking effort by hand. Regular OpenAI choices use Opser credits. ## Set the thinking level The thinking level controls how much reasoning a model does before it answers: **Off**, **Minimal**, **Low**, **Medium**, **High**, and — on models that support it — **Xhigh**. More thinking can improve hard analysis but takes longer and uses more credits; less thinking is faster and cheaper for straightforward tasks. Not every model supports every level, so if you switch models the level may adjust to the closest one available. ## Give the agent a role General also includes the agent's **personality** and **knowledge**. Personality describes how it should behave and communicate. Knowledge supplies domain facts and standing instructions for its role. These are separate from the organization's shared context and from the current conversation. Choose the intended agent before editing. Each agent has one configuration, used for everyone who can use it; changing one agent does not change another. On an agent other people use, only its owner or an admin changes these settings. See [Context & memory](https://docs.opser.com/agents/context/). ## Connect a ChatGPT account Open **Settings → Profile** and use **Linked accounts** to run a **Connect ChatGPT** flow that lets your agents use models from your own ChatGPT subscription. Start the connection, follow the sign-in steps, and return to Opser to confirm the connected state. Agents you own can access your account’s connection; a connection made earlier on a specific agent remains listed and manageable there. Never paste account credentials into a conversation. Once connected, the model selector adds a second **Advanced** and a second **Expert** choice, each with a colored **Subscription** tag. The Custom dialog keeps regular GPT models in **OpenAI · Opser credits** and adds a separate **OpenAI · ChatGPT subscription** section. Only choices carrying the Subscription tag use your ChatGPT plan; the untagged Advanced, Expert and OpenAI choices continue to use Opser credits. ## Understand the cost boundary A connected subscription and Opser credits are different billing arrangements. Model work runs on Opser credits unless it uses a connected account, which bills against that provider's own plan and limits. Connecting an account does not make every tool, integration, or generated artifact free — check the [Usage](https://docs.opser.com/billing/usage/) view for what a given kind of work consumes. ## Change or disconnect Save your model and thinking choices in General. Use the **Linked accounts** controls in Profile to disconnect when you no longer want your agents to use a connected account. If a model stops being available, choose another from the list and check the account connection before retrying. --- # Persistent files & workspace How an agent keeps source files, scripts, and results from one task to the next. Source: https://docs.opser.com/agents/files/ ## A filesystem that lasts beyond a chat Each agent has its own persistent workspace. It can keep uploaded inputs, scripts, working notes, and generated files there, then use them again in later work with the same agent, including its automations. Ordinary runtime restarts use the same workspace rather than starting with an empty directory. Your chat with the agent never resets, and compacting it does not remove files. The agent can find the files from earlier in the chat, what you sent and what it made, so you can ask for “the report you made last month”. It does not read every saved file on each request: give it the filename or describe the material when you want to continue earlier work. ## Inputs, scripts, and results The agent can read and write files and run code against them. It commonly uses workspace locations such as `uploads/` for inputs, `artifacts/` for results, and `.tmp/` for scratch work. Exact filenames come from the task and its tools. > Use the source spreadsheet and comparison script we saved last week. Run the same checks on this new file and save this week's report separately. Ask it to keep a reusable script when a task involves repeatable transformations or checks. A saved script gives a later run a concrete starting point; [Code & scripts](https://docs.opser.com/capabilities/code/) explains the execution environment. ## Attach and inspect files Attach a file to your message and explain which sheet, pages, columns, or records matter. To see every file in the chat, what you uploaded and what the agent made, open the gear in the chat's header and choose **Files**. Results also appear as files in the conversation. Open the actual output and check its values, formulas, and layout. If a tool fails, a message promising a file is not enough: ask for the saved result and verify it opens. ## Working files and business storage | Location | Use it for | | --- | --- | | Agent workspace | Source material, scripts, intermediate work, and artifacts for that agent | | Workspace storage | Stored files and attachments referenced by business records | | An installed app | Documents or records that need the app's organization, sharing, and workflow | Keeping a file in an agent workspace does not publish it or make it a shared app record. Ask the agent to store the final file in the intended destination. The storage capability can move a file from the workspace into storage and fetch it back for later work. When a recipient needs a link outside Opser, make that intent explicit. Supported sharing includes expiring links and public links that can be revoked. A public link is a separate sharing decision; do not confuse it with an ordinary in-app attachment. ## Scope and lifecycle The workspace belongs to the agent. Switching to a different agent means using a different filesystem. An agent other people can use keeps one workspace for all of them, so choose the agent with the intended team audience. Persistence is not a backup policy. Files you delete are no longer available, scratch work should not be your only copy of an important result, and deleting an agent can remove its workspace. Store important deliverables in the appropriate business location before removing an agent. [Storage allowances](https://docs.opser.com/billing/plans/) also apply to ongoing work. --- # Schedules & automations Turn a useful workflow into work that runs at the right time or in response to an event. Source: https://docs.opser.com/agents/automations/ ## Start with a working task The simplest way to set one up is to ask the agent in its chat. Say what should happen and when: the agent uses your workspace context, asks about anything unclear, and creates the automation. Agree on the task, source records, destination, and timezone before it does. On an agent other people use, everyone with access sees, sets up and changes its automations, unless its owner turned that off; then only its owner or an admin does, and the results still appear in the agent's chat. > Every Monday at 9 a.m. in my timezone, summarize overdue tasks by owner and send me a short update. Do not change task statuses. You can also ask for the task once in the chat first. Check the saved schedule rather than assuming that “tomorrow morning” means the same time to everyone. ## Schedules and event triggers To set one up yourself, open the gear in the chat's header, choose **Automations**, then **New automation**, under the section's description. Give it a title, write the task in **What should this automation do?**, and choose **Add trigger**: **Automations · Fictional data** A briefing runs Mondays at 09:00 Europe/Rome. A second automation responds to a customer-request app event. Both are enabled. - **On a schedule:** repeats hourly, daily, weekly, or monthly at the time you pick, in your timezone. - **Once:** runs one time, at the date and time you pick. - **When something happens:** runs on an app event. Choose an installed Opser app or a connected account, then one of its events. Opser app events need no connected account. The agent receives the event details when it runs. Choose **Create** to save it; close the form to drop it. If nothing can start an automation, **App** shows **No apps installed**; an app without exported events shows **No events available**. Available apps and events depend on the workspace and the agent's access. The agent can discover these same app events, and the events of its connected accounts such as a new email in Gmail, when you ask for an automation in the chat. ## Review ongoing work New automations, whether you create them or the agent does, run automatically by default. Creating one pre-approves the actions described in its task, including sending emails and updating app data. There is no separate app-access checklist or per-action approval prompt during those runs. Be precise about the intended actions and recipients. Automatic execution still requires valid app permissions, connected accounts, and available usage credits. It does not grant new access. Older automations retain their original execution restrictions. A schedule without valid authorization pauses with **Needs authorization** instead of repeatedly failing or losing its saved task. Each run works on its own, and its results show in the agent's chat; they reach the agent with the next message in the chat. Every run lists in the **History** tab, beside the automations. Check the first one there: **View** opens the chat at that run's latest message, and a run waiting on you shows **Review**, with the approval above the composer. Inspect the result before relying on it. If required access is missing, fix that access rather than repeatedly retrying the task. When weekly-review email delivery is enabled for your workspace, a successful default weekly-review run can also send a report to the default agent’s owner. Delivery depends on the available evidence, email preferences, and frequency limits. A failed run does not send its report. Review the result in the chat and manage optional emails in **Settings → Notifications**. For a failed scheduled run, ask the agent to inspect its diagnostics without rerunning it. The agent can show recorded errors, attempts and tool operations that you are allowed to see in the chat. An attempted action does not confirm a saved change; check the affected records before retrying. Recorded detail can be incomplete, especially for older runs or worker interruptions. ## Pause, edit, or remove Use the automation controls to pause, change, or remove work you no longer need. You can also ask the agent in chat to adjust an existing automation: it updates the schedule, task, timezone, or event source in place, so the automation keeps its identity and run history instead of being deleted and recreated. If the automation changed in the meantime or a run is in progress, the edit is rejected rather than applied blindly. Changing an automation someone else set up makes it yours: it runs with your access from then on. Each automation lists its trigger with a distinct icon and label, so schedules, app events, and integration events are easy to tell apart. Review existing automations before creating a replacement to avoid duplicate runs. If a run fails or a connection is interrupted, inspect its history and the affected records before retrying: an action may already have completed. ## Authorize a paused schedule If a scheduled automation shows **Needs authorization**, anyone who may change its automations can choose **Authorize**. Review the saved task and confirm **Authorize and resume**. The automation then runs with your access. Keep **Automatically carry out the actions described in this task** off to retain its existing tool restrictions, or explicitly turn it on to pre-approve the actions described in the task. This does not grant additional app or connected-account access. Authorization keeps the automation's identity, task, schedule, and history. It does not run the task or replay missed occurrences: a future date stays unchanged, and a recurring schedule whose date has passed resumes at its next future occurrence. A one-time schedule in the past needs a new date first. Reviewing and authorizing the schedule does not launch an agent run or consume model credits. --- # Connect your tools Give an agent access to the external accounts it needs for a task. Source: https://docs.opser.com/agents/integrations/ ## Connect an account Open the agent's settings with the gear in the chat's header and choose **Plugins**; it opens on the **Integrations** tab. Select **New integration**, under the tab's description, and choose an available service. Follow the connection flow and approve the requested scopes with the external provider. Return to Opser and verify the connection is active. **Integrations · Fictional data** Gmail and Google Calendar are connected to maya@northstar.example for this example agent. Available services depend on the workspace. You can also ask the agent to connect a supported integration. Complete the sign-in step yourself when the agent gives you a connection link. Never send passwords, session cookies, or secret API keys as chat messages. ## Choose the right account and agent Check which agent you are configuring and which external account you authorize. A connection belongs to the agent, not to you: everyone with access to the agent can have it work in that account. An installed app’s mailbox access is a separate scope. Connect only accounts that everyone with access to the agent may use. On a specialist agent, everyone with access can connect their own accounts; each person can disconnect the accounts they connected, and its owner or an admin any of them. If an installed app also uses that service, review the app’s separate connection and access settings. ## Use the connection Name the service and the outcome in your request. The agent can discover supported operations and use the permissions granted by the provider. Some writes may require approval. > Find next week’s customer meetings in the connected calendar and prepare a briefing from the related CRM accounts. Do not send any messages. Available services and operations depend on what your environment supports. A familiar service name is not a promise that every feature of that service is exposed in Opser. ## Reconnect or disconnect Expired authorization, revoked scopes, and changes at the provider can break a connection. Check its status, reconnect if necessary, and retry a small read before repeating a write. Disconnect an account you no longer use from **Plugins**, or ask the agent in its chat; it asks you to approve first. Automations that the account runs are removed with it, so review any schedules or workflows that depended on it. ## App integrations Some apps use administrator-managed connections for their own operations. Those may have separate configuration and access controls from the agent’s account connections. --- # What Opser can do A practical guide to the work your agents can take on, and what each capability needs. Source: https://docs.opser.com/capabilities/overview/ ## Choose an outcome Opser agents combine platform tools, installed app tools, and connected services. Start with what you want to achieve; the agent can choose the appropriate tools when they are available. | Work | Start here | | --- | --- | | Process files with reusable code | [Code & scripts](https://docs.opser.com/capabilities/code/) | | Find and update structured records | [Data and reporting](https://docs.opser.com/capabilities/data/) | | Analyze PDFs and prepare documents | [Documents and PDFs](https://docs.opser.com/capabilities/documents/) | | Clean, calculate, and export tabular data | [Spreadsheets](https://docs.opser.com/capabilities/spreadsheets/) | | Prepare a slide deck | [Presentations](https://docs.opser.com/capabilities/presentations/) | | Generate supported images, video, or audio | [Media generation](https://docs.opser.com/capabilities/media/) | | Investigate public sources | [Web research](https://docs.opser.com/capabilities/research/) | | Create a workspace tool | [Internal app building](https://docs.opser.com/capabilities/internal-apps/) | | Build a separate website or portal | [External app building](https://docs.opser.com/capabilities/external-apps/) | | Assemble an overview of your work | [Dashboards](https://docs.opser.com/capabilities/dashboards/) | | Run recurring or event-driven work | [Schedules and automations](https://docs.opser.com/agents/automations/) | | Work across external accounts | [Integrations](https://docs.opser.com/agents/integrations/) | See [Built-in tools](https://docs.opser.com/agents/tools/) for the platform foundation behind these workflows. ## More than a single tool call A task may involve several steps: reading records, asking a question, analyzing files, delegating a bounded piece of work, and preparing a result. The conversation brings those steps together. The agent can use its workspace to process files and run supporting code when the environment permits it. **A plan in progress · Fictional data** Data inspection is complete, the portal build is in progress, and access review and testing are pending. Some tools become available only when relevant to the task. Installed apps contribute their own actions; the app’s interface and its agent tools work with the same underlying records. ## What controls availability A capability needs the appropriate workspace configuration, permissions, and sometimes a connected account. Some operations consume credits in addition to the model’s usage. Review [usage and credits](https://docs.opser.com/billing/usage/) and [approval rules](https://docs.opser.com/agents/approvals/) before automating a costly or consequential workflow. When something is unavailable, ask the agent which dependency is missing. A different model alone will not install an app, authorize a mailbox, or grant permission. --- # Code & scripts Let your agent write and run code to process files, check results, and complete custom tasks. Source: https://docs.opser.com/capabilities/code/ ## Ask for the result, let the agent write the code Opser agents can write and execute scripts as part of getting work done. This is useful when a task needs repeatable calculations, a custom transformation, validation across many files, or a step that does not fit a single app action. > Compare these two exports, normalize the dates, and produce a file listing added, removed, and changed records. Save the comparison script so we can run it again next month. You do not need to write the script yourself. Explain the inputs, rules, desired output, and what must stay unchanged. ## How execution works The agent uses its file capability to inspect or write source and its shell capability to execute commands. Commands run in the agent's working environment, with the workspace as their starting directory. Results and errors return to the conversation. The available commands, language runtimes, and libraries depend on that environment. The agent should check what is installed before choosing an approach. A script that has been written is not a script that has run successfully; inspect the execution result and output file. ## Persistent scripts and inputs The agent's [filesystem persists](https://docs.opser.com/agents/files/) from one task to the next. Save scripts and meaningful inputs with clear names so later tasks can find them. Ask the agent to explain the script's inputs and outputs, especially if someone else will reuse it. For a recurring comparison, keep the original source unchanged and save each run's output separately. Check a small sample, totals, and missing values before relying on the complete result. A schedule can reuse a working approach when the necessary files and access are available. ## Working with business records Use app tools for records owned by an app, and the data capability for supported user-managed datasets. Running code does not grant access to another app's private tables, a colleague's files, or a service that has not been connected. The agent can combine these capabilities: retrieve authorized data, process it in its workspace, and write the result back through the supported interface. Ask it to show the destination and proposed changes before a consequential update. ## Control and limits Shell execution is restricted to the agent's environment, and the tool can be disabled by an agent's tool restrictions. Commands do not inherit the platform process's secret configuration. Changes such as deletion, overwriting, publishing, or external writes can require approval under the action's rules. Code can still make mistakes. Give the agent a review point for important work and verify the output. Long-running or unavailable commands can fail; ask for the actual error and completed steps before retrying. A saved script is also different from a deployed app. If teammates need a durable interface and shared workflow, use the [internal app builder](https://docs.opser.com/capabilities/internal-apps/). --- # Data & reporting Turn business records and source files into useful answers, with a clear route back to the evidence. Source: https://docs.opser.com/capabilities/data/ ## Work with structured information Ask the agent to find, compare, summarize, or update data in the apps you can access. Identify the app and useful filters such as date range, owner, customer, or status. > In Sales, summarize confirmed orders due next month by customer and currency. Include order links and flag orders without a delivery date. For data outside an installed app, the platform’s data capability can work with structured entities and records. When you need a reusable user interface around that information, consider an [internal app](https://docs.opser.com/capabilities/internal-apps/). ## App-owned records and user-managed datasets Apps own their tables and business rules. Use their supported tools or exposed operations for those records. The platform data tool manages user-owned business datasets separately: entities, fields, relationships, records, and their access settings. The agent can inspect an existing dataset, define a structure, import records, and query it for analysis. Supported SQL reporting is read-only and scoped to the permitted business data. It is not an unrestricted query interface into private app or platform tables. ## Build a report Specify the audience, date range, grouping, and output format. Ask for source references or record links so you can check the result. Keep currencies and units explicit. 1. Confirm which records are included and excluded. 2. Check the grouping and calculation rules. 3. Inspect a sample of the underlying records. 4. Choose a useful output: a conversation summary, spreadsheet, presentation, or dashboard. Missing data should be visible in the result. Ask the agent to flag uncertainty instead of filling gaps with assumptions. ## Make changes carefully Separate exploratory analysis from bulk updates. Ask for a preview that identifies the affected records, then review it before authorizing the change. Permissions and tool-specific approval rules still apply. > Show me the contacts with missing company names. Suggest matches using their email domains, but wait for my review before saving changes. ## Repeatable reporting Use a [skill](https://docs.opser.com/agents/skills/) to keep a report format consistent, and a [schedule](https://docs.opser.com/agents/automations/) to run it regularly. For a continuously useful workspace view, see [Dashboards](https://docs.opser.com/capabilities/dashboards/). ## Discover tables and columns without truncated results The agent's `data.describe_schema` action returns a table inventory in pages of 25 (up to 50). Use `search` to narrow table names, then follow `next_input` until it is null. Specify `entityId` to inspect the exact column names in one table; those fields are paged too. This avoids guessing names such as `sort_order` when the real column is `position`. Discovery keeps the person's and agent's existing app/data access checks. Dashboard's `list_data` action has the same `limit`, `offset`, `search` and `next_input` workflow. Exact row counts require `include_record_count: true` (`includeRecordCount` on the data tool); ordinary discovery skips those counts. These are tool controls, not changes to the Settings → Data browser. ## SQL reporting boundaries `raw_sql` accepts one read-only SELECT or WITH query, including literal labels, UNION/UNION ALL, DISTINCT, aggregates and approved casts. Results are capped at 500 rows and the database query has a 15-second deadline. Only business tables the person and requesting agent may read are eligible. Reporting does not change app records or grant access to platform/private tables. Text projections include `strpos`, `position`, `regexp_matches`, `regexp_replace`, `lower`, `substring` and `split_part`. JSON inspection includes `jsonb_object_keys`, `json_object_keys`, JSON extraction and JSON array length. Use key-expansion functions in SELECT; function sources in FROM and schema-qualified calls remain unsupported. An unsupported function error lists the allowed functions. Arbitrary functions and unsafe casts remain rejected. For exact-person research, prefer parameterized word-boundary regexes over broad substring searches: for example, `regexp_matches(note, ?, 'i')` with `params: ["\\mPier\\M"]`. Inspect the schema first, select only needed columns, and use a small limit. A substring such as `mark` can also occur in `marketing`; SQL support does not automatically decide whether a mention identifies the intended person. --- # Documents & PDFs Read source documents, extract useful information, and prepare documents people can act on. Source: https://docs.opser.com/capabilities/documents/ ## Analyze a PDF Attach a PDF and explain the questions to answer. Ask for page references where the source supports them, especially when reviewing terms, quantities, or specifications. > Compare these two supplier offers. Extract unit prices, minimum orders, delivery terms, and validity dates. Cite the page for each value and flag anything you cannot read reliably. Text PDFs, scanned pages, and complex layouts can produce different extraction quality. Review critical values against the original document. ## Create a document Describe the audience, purpose, structure, and format. The document and PDF capabilities can help prepare customer-facing material, reports, and structured output from your workspace information. A useful brief includes the recipient, facts to include, tone, branding requirements, and sections to omit. If you have a template, attach it and identify which parts should remain consistent. ## Use a workflow skill The skill catalog includes PDF Analysis, Supplier Offer Extraction, Customer-Facing Documents, Runbook, Status Report, Risk Assessment, Process Documentation, Vendor Review, and Compliance Tracking. Ask the agent to use the relevant skill for a more consistent process; if it is not installed yet, the agent finds it in the catalog and asks before installing it. For shared knowledge or collaborative documents, use the appropriate installed app. Confirm where the result is stored and who can access it; see [how apps work](https://docs.opser.com/apps/overview/). ## Review before sharing Open the output and check names, dates, numbers, layout, links, and missing information. Generated documents should accurately reflect the source records. A draft compliance tracker or risk assessment is a working aid; your team remains responsible for reviewing its conclusions. --- # Spreadsheets Clean source data, calculate results, and produce spreadsheets you can inspect and reuse. Source: https://docs.opser.com/capabilities/spreadsheets/ ## Give the agent the source and the rules Attach your spreadsheet or identify the app data to use. Name the relevant sheets, the meaning of each column, and the output you want. > Clean this customer export. Normalize whitespace, identify duplicate email addresses, and create a separate sheet listing proposed merges. Preserve the original rows. For calculations, state the units, currencies, date interpretation, and rounding rules. Ask the agent to explain important formulas and assumptions. ## Analyze and create The spreadsheet capability supports working with tabular files and producing spreadsheet artifacts. Use it for comparisons, reconciliations, planning tables, and exports. The agent may use supporting code to process larger or more involved datasets in its workspace. A generated spreadsheet file is an artifact you can download or store. If your workspace has an app for collaborative documents, tell the agent whether you want an editable record in that app or a downloadable file. ## Check the workbook Open the finished file and inspect the sheet names, headers, totals, formulas, and formats. Test a few known rows. Review date and decimal conventions when data comes from different locales. Complex source workbooks can contain features that do not survive every transformation. Keep an original copy and explicitly call out formulas, formatting, or workbook features that must be preserved. ## Move from analysis to action Once the result is approved, ask the agent to update the relevant app records or save the output to the right location. A spreadsheet analysis does not itself update the system of record. --- # Presentations Turn an outline and evidence into a presentation with a clear audience and purpose. Source: https://docs.opser.com/capabilities/presentations/ ## Start with the story Tell the agent who the presentation is for, what decision it should support, and how long you have to present. Provide source material and any brand or template requirements. > Create a six-slide monthly operations review for our leadership team. Use the attached report. Cover results, missed targets, causes, and next month’s priorities. Keep all numbers traceable to the source. Ask for an outline first when the topic is complex. It is easier to change the story before producing all the slides. ## Create and refine the deck The presentation capability and Presentation Creation skill help structure and generate a deck. Review the output artifact, then request specific revisions: simplify a crowded slide, clarify a chart, or move detail into supporting material. ## Check the final artifact Open the presentation in the application you intend to use. Check text overflow, image cropping, chart labels, fonts, and the accuracy of figures. Confirm that each slide communicates one useful point and that the sequence supports the intended conclusion. For new images, see [Media generation](https://docs.opser.com/capabilities/media/). For source analysis, see [Data and reporting](https://docs.opser.com/capabilities/data/). --- # Images, video & audio Create supported media assets from a brief and refine them for the intended use. Source: https://docs.opser.com/capabilities/media/ ## Describe the asset Give the agent the purpose, subject, style, dimensions or aspect ratio, and intended destination. Attach a reference when you want to preserve a particular look or modify an existing asset. > Create a simple landscape illustration for an internal onboarding guide. Use muted green and neutral colors, leave space for a heading on the left, and include no text in the image. The media capability supports image, video, and audio operations according to the models and providers configured in your environment. Available formats, durations, and editing options depend on the selected operation. ## Review the proposed operation Media generation can consume credits. Be clear about the number of variants and the level of iteration you want. For an expensive request, ask the agent to explain the planned operation before proceeding. ## Refine and export Open the generated artifact and check whether it fits its destination. For images, inspect small details and any rendered text. For video, check the full sequence. For audio, listen to the entire output and check pronunciation and timing. Ask for a specific revision rather than restarting with an unrelated brief. Use material you are authorized to supply and publish. ## Store the result Save approved assets in the appropriate workspace location, using [workspace storage](https://docs.opser.com/workspace/data/) or an installed app, or use them in a document, presentation, or app. Generated media remains subject to your workspace’s [storage and usage allowances](https://docs.opser.com/billing/plans/). --- # Web research Investigate public information and keep the findings connected to their sources. Source: https://docs.opser.com/capabilities/research/ ## Ask a focused question Give the agent a question, scope, and freshness requirement. Identify sources you consider authoritative and ask for links supporting the conclusions. > Compare the published return policies of these three suppliers. Use their official websites, link to each policy, and flag any terms you cannot verify. Opser can fetch public pages, search, and scrape supported content. A managed browser can inspect rendered public pages when simpler methods cannot read them. ## Browser research has a specific scope The browser research capability is read-only. It investigates public pages and can expose a live preview when available. It does not log into accounts, submit forms, send messages, place orders, or make purchases. Use a supported [integration](https://docs.opser.com/agents/integrations/) for authorized account operations. Browser interaction used while testing an agent-built app is a separate app-building capability. ## Evaluate the answer Check that cited sources support the claims and that the dates are appropriate. Ask the agent to distinguish facts from inference and to report conflicting evidence. A page may be blocked, removed, region-specific, or incomplete. ## Costs and limits Search, scraping, and managed browser research can have different usage costs. The agent should use an appropriate method for the task; opening a complex page in a managed browser may consume more than a straightforward fetch. Inspect [Usage](https://docs.opser.com/billing/usage/) for the work performed. --- # Your browser Let an agent work on the sites you're signed in to, in your own Chrome or in Opser's cloud browser. Source: https://docs.opser.com/capabilities/your-browser/ ## Let an agent work in your browser Many sites you use have no Opser app or integration: a supplier portal, a carrier's booking site, an older system your team signs in to. With the Opser Chrome extension signed in to your workspace, an agent can work on those sites in your own Chrome, signed in as you. > Open the Northwind supplier portal, find order PO-20817 and tell me its delivery date. The agent opens its own tab, reads the page, and clicks, types and chooses options the way you would. To have it work in a tab you already have open, say which one. It keeps going until the task is done, and asks you only when you have to act yourself: signing in, a two-factor code, a CAPTCHA, or a choice only you can make. ## Chat beside the page Click the Opser icon in Chrome's toolbar to open your agents in Chrome's side panel. Choose an agent from the menu and ask about the page you're on: it finds your open tabs and works in the one you mean. Records an agent links to open in a normal tab. The extension is only for your agents: it doesn't record meetings or read pages on its own. ## What you see while it works The tab an agent works in glows blue and says which agent is using it. Tabs it opens sit together in a blue Opser tab group. Chrome also shows its own bar saying the extension is debugging the browser. In the chat, each step shows as it happens, such as opening a page or clicking. An agent never drives your Opser workspace itself in your browser; it uses its Opser tools for that. It closes only the tabs it opened. ## Stop it at any time Press Stop on the glowing tab, or Cancel on Chrome's bar, and the agent lets go of your browser at once and ends that task. Your next request can use your browser again. In the side panel, Opser in Chrome (at the bottom of the menu) has the switch that turns agents off for this browser and back on, and shows who is working. When you've turned them off, an agent asks you before carrying on. ## The cloud browser An agent can also use Opser's cloud browser, which works when your computer is off. It keeps the sign-ins you make in it for next time. When a site needs you, the chat shows you a button to take the cloud browser over: sign in or pass the check, tell the agent you're done, and it carries on. Only you can open it. ## Automations A scheduled automation can use the browser of the person who set it up, while they're still a member of the agent, or the cloud browser. If their browser isn't connected, the run says so instead of trying again and again. Steps that change something, such as clicking, typing or going back to a submitted form, count as done, so a retried run doesn't repeat them. ## Costs and limits Working in your own browser costs only the agent's usual model use. The cloud browser also bills the time it runs; check [Usage](https://docs.opser.com/billing/usage/). Read the form before letting an agent submit anything that sends, buys, books, pays or deletes; for now an agent doesn't ask for approval before it acts in a browser. --- # Website analytics Track Opser apps and other websites, understand traffic metrics, and review privacy and access. Source: https://docs.opser.com/capabilities/analytics/ ## Track your website traffic Analytics shows visitors, pageviews, traffic sources, campaigns, countries, devices, and custom events for your websites. Open **Analytics** from your workspace's apps to choose a website and explore its dashboard. If the app is missing, install it from the App Store or ask an admin. Tracking must be available in your workspace's region. Analytics starts collecting after you enable tracking; adding a website does not recover earlier traffic. ## Enable tracking for an Opser app Open a published [external app](https://docs.opser.com/capabilities/external-apps/), select its **Analytics** section, and turn on tracking. Opser adds the tracker automatically: you do not need to edit code or republish. You can also find your workspace's Opser apps and their tracking switches under **Add website** in Analytics. Open the website's dashboard in Analytics to see its traffic. Turn tracking off from the external app's page when you want to stop collecting. Its tracked domains follow the app's domains. ## Connect a website hosted elsewhere In Analytics, choose **Add website**, enter a name and the domains to track, and create the website. Open its setup or website settings to copy the tracking snippet. Paste the exact snippet into the head of every page, or the shared layout, then publish your website changes. The snippet contains your website's identifier and the correct collector address. Alternatively, choose **Copy prompt** under **Let your AI agent set it up** and give it to an agent that can edit your website's code. The prompt includes the snippet and installation instructions. Ask the agent to show what it changed and verify the published site. Visit the public site in a normal browser. The dashboard waits for the first recorded visit; localhost visits and automated browsers are ignored. Do not install a second snippet on an Opser app whose tracking switch is already on. ## Understand the figures Choose a period and compare it with the previous period of the same length. Dates follow the workspace's time zone, set under **Settings → Organization**. Click a page, source, campaign, country, or device to filter the dashboard. | Metric | What it means | | --- | --- | | Visitors | Anonymous device-and-browser counts per day. A person returning tomorrow counts again; this is not a count of unique people. | | Visits | Groups of activity that end after 30 minutes without events. | | Pageviews | Recorded page loads and supported single-page navigation changes. | | Views per visit | Average pageviews per visit. | | Bounce rate | Percentage of visits with one pageview and no further events. | | Visit duration | Average time between a visit's first and last recorded events. A visit with only one event has zero duration. | | Live visitors | Visitors recorded in the last five minutes. | Detailed data covers the last 13 months. Agents can also read older monthly summaries. Large queries may use sampled data; treat figures marked approximate as estimates. ## Privacy and access The tracker uses no cookies or browser storage to identify visitors. IP addresses are used to determine country and generate an anonymous daily code, then discarded. The code changes daily and is specific to each website. Statistics stay in the workspace's region. Known bots are excluded. Keep personal information out of custom event names and properties. Use **Analytics → Settings** to review the privacy explanation and pageview allowance. The permission `analytics.view` allows reading websites and statistics; `analytics.manage` allows managing tracked websites. External-app tracking controls require `external-apps.manage`. An agent also needs access to the Analytics app. An admin manages grants under [Settings → Permissions](https://docs.opser.com/workspace/permissions/). ## Ask your agent about traffic > Compare our website's traffic over the last 30 days with the previous period. Show the top pages and sources, and tell me whether any figures are approximate. Name the website when you track several. Analytics tools read statistics; they do not change tracking settings. Custom events appear after your website code sends them, so describe the action you want measured when asking an agent to implement one. ## If no traffic appears Check that tracking is enabled, the website is published, and the visited domain is listed. For another host, check that the snippet appears once in the published pages and that the browser can load it. A blocked tracker, local test, or automated visit will not prove tracking works. If Analytics reports that the service is unavailable, ask your admin to check regional availability. If collecting is paused because of the pageview allowance, review **Analytics → Settings** and [Plans & credits](https://docs.opser.com/billing/usage/): unpaid usage can pause collection after a grace period. Missing visits during a pause are not backfilled. --- # Dashboards & live views Turn the data you can access into a useful dashboard without building another app. Source: https://docs.opser.com/capabilities/dashboards/ ## Make a dashboard useful to you Ask your agent to arrange the dashboard in the **Dashboard** app around the information you check regularly. It can inspect the current layout, add or update supported widgets, and adjust their configuration. You do not need to build an app just to show a metric, a list, or a table. To land on it when you open Opser, pick it as your [home page](https://docs.opser.com/workspace/preferences/). **Your Home dashboard · Fictional data** Example widgets show 12 open requests and 3 needing review. REQ-104 from Acme Studio is in progress; REQ-105 from Juniper Labs is pending. > Add a compact view of the open requests I can access, grouped by status. Put the total above a table of the oldest requests. Keep my existing widgets. Name the source and the question the view should answer. The agent should check what data is available before choosing a widget. The agent's dashboard tools come with the Dashboard app, so they are there only when the app is installed and you can open it. Earlier versions of the app do not include them: when the Dashboard app shows **Update available**, someone who manages apps can install the new version with **Update app**. See [Managing apps](https://docs.opser.com/apps/managing/). ## Where the data comes from A widget can show any business data you can read: your own datasets and the tables of the apps you can open. The Dashboard app reads them the way the agent's data tool does, read-only, so a dashboard never shows an app you cannot open and never changes a record. When an app offers a read operation for composition, the agent prefers it: the operation keeps the app's own logic and keeps working when the app changes its tables. Otherwise the widget queries the tables directly, and the agent runs the query before saving the widget. See [How apps work together](https://docs.opser.com/apps/connected/). ## Metrics, tables, and custom views The agent can build read-only metrics, charts, tables, lists, and supported custom views. Give it the grouping, date range, units, and empty-state behavior you expect. A useful view shows its meaning clearly: distinguish a count from a currency value, keep the date range visible, and verify the result against the source. Custom views use supported display components rather than an unrestricted web application. ## Refine and restore the layout Ask for a focused change to the current layout. The dashboard keeps revision history so an earlier layout can be restored as a new revision. Restoring a layout does not roll back the underlying business data. Check the populated dashboard after a change, including narrow screens and empty results. Refresh behavior depends on the widget configuration; a view is not necessarily updated at the exact instant a source record changes. --- # Build an internal app Turn a business workflow into an app inside your Opser workspace. Source: https://docs.opser.com/capabilities/internal-apps/ ## Describe the workflow An internal app gives people and agents a shared place to do a kind of work inside Opser. Describe the users, records, steps, views, and access rules. Include the actions you want the agent to perform through tools. > Build an equipment checkout workflow. Track assets, borrowers, due dates, and returns. Staff can request a checkout; coordinators approve it. Include an overdue view, search by asset tag, and agent tools for finding and returning equipment. The agent should inspect installed apps before deciding to create a new one or edit an existing app. A [dashboard](https://docs.opser.com/capabilities/dashboards/) may be enough for an overview. App building needs to be enabled in your environment; if the builder reports it is unavailable, ask your administrator about that capability. ## Review a draft with separate data The agent creates or opens a draft and works on its source files. The draft has a live preview and version history. Its database sandbox contains the business schema without production records; use synthetic examples to exercise the workflow. Edits rebuild the draft preview. Review the real screens, navigation, forms, required fields, empty states, error handling, and mobile layout. A preview is separate from the installed version your team uses. ## Build the agent and app interfaces together Ask for useful tools and skills alongside the screens. The human action and agent action should apply the same validation and business rules. If the app connects to another app, specify its [contracts, events, and notifications](https://docs.opser.com/apps/connected/). Test with the intended permissions. Check a normal workflow, an invalid request, and an attempt to access a record the user should not see. A polished screen alone does not verify the app's behavior. ## Test and install the reviewed version The builder runs tests and readiness checks over the source and declared platform capabilities. These include permissions, resource bindings, tools, data ownership, and the app's declared connections. Resolve blocking feedback and review the preview before installing. An authorized user can install the reviewed draft into the workspace. A user without installation permission can submit an installation request for an administrator to review. Installing an edit upgrades the existing app; it does not create a second copy. ## Who can change an app Everyone with access to an installed app can use it. Only the people on its list can change it. The person who first publishes an app becomes its owner, and **Settings → Apps** shows the owner on the app's row. Select **People** to see the list. The owner can add editors, who can change and publish the app, remove them, or make someone else the owner. When the owner is not available, an admin can open **People** and select **Take ownership**. The previous owner stays on the app as an editor, and the change appears in [activity](https://docs.opser.com/workspace/activity/). Agents follow the same list. If you ask your agent to change an app you are not on, it tells you who owns the app so you can ask to be added. ## History and ongoing changes Ask for focused changes and inspect the diff or history when reviewing an update. Restoring an earlier draft source creates a new source revision and rebuilds its disposable preview data. It does not roll back production business records. When another update has changed the installed app, the draft may need to be reconciled with that newer version before installation. Preserve the newer behavior as well as your intended customization. Use **Settings → Apps** for installed apps, work in progress, and operation history. See [app management](https://docs.opser.com/apps/managing/) for lifecycle details. --- # Build an external app Create a separate website or portal while keeping the build connected to your Opser workflow. Source: https://docs.opser.com/capabilities/external-apps/ ## A separate web experience An external app is a website or web application outside the Opser workspace interface. Use it for a public site, a customer portal, or another audience that needs a separate experience. An [internal app](https://docs.opser.com/capabilities/internal-apps/) instead runs inside the workspace. > Build an onboarding portal with a welcome page, a checklist, and a company-details form. Show which pages are public, what requires sign-in, and where submissions will be stored. The builder supports a static frontend connected to Opser's platform services. Describe the experience and data boundaries rather than assuming a separate server or unrestricted workspace connection is available. ## Declare data and access The app declares the data tables and capabilities it needs. The platform uses those declarations when preparing the app's data and publishing it. Access to an installed app or a user-bound capability needs the corresponding grant. Review what a visitor may read or change and whose authority a capability uses. A public page must not expose workspace data merely because the app's owner can access it. If publication reports a missing capability grant, the agent can request that grant for review in the conversation. ## Who can see an app Each external app has its own access list. The person who creates it becomes its owner, and nobody else sees it until they are added. Open the app and select **Sharing** to see who has access. The owner can add people as an editor, who can change and publish the app, or a reviewer, who can look at it. The owner can also change a role, remove someone, or make someone else the owner. Admins see every external app in **Settings → Apps**, together with its owner. An app they are not on opens read-only, with **Join as editor** and **Take ownership**. Taking ownership keeps the previous owner on the app as an editor. Admins can also change any app's access list. This comes from the `external-apps.manageAll` permission, which admins hold; grant it on **Settings → Access** to give someone else the same oversight. Permission to build external apps does not by itself show other people's apps. Agents follow the access list only. An agent works on an app only when its person is on that app's list. ## Preview and verify Opening an external app takes you to its dashboard while the protected preview loads in the background. Select **Preview** to view the app. Switching between Preview and Dashboard keeps the same preview open, so you can review settings without restarting it. A first start can take longer while dependencies and the preview environment are prepared. The agent can build the app, run its checks, inspect logs, and open a protected preview. Review navigation, forms, loading states, mobile layouts, and access by an unauthorized visitor. Preview data is separate from production. Capability calls can be stubbed in the preview, so a successful preview is not evidence that a live integration completed an action. Verify the granted capability flow on the published app as well. ## Publish and connect a domain Publishing creates a deployment revision and returns its public URL. Inspect that result before sharing it. Building and publishing depend on the services configured in your environment. For a custom domain, the setup returns the required traffic and ownership-verification DNS records. Create the exact records shown and check domain status. A verified domain can still be waiting for its certificate; confirm HTTPS is active before treating the domain as ready. ## Update, unpublish, and restore Source history lets you review changes and restore an earlier source version as a new revision. Source restoration and data restoration are different operations; do not assume returning to an earlier interface also returns the database to an earlier state. Unpublishing removes the public deployment while preserving the app, source, settings, history, and data for later publication. Review the specific operation before a teardown or data restore. Confirm where user submissions are stored and how they will be handled after the app is taken offline. --- # How apps work Software your team and agents use together, built around your business. Source: https://docs.opser.com/apps/overview/ ## Software that fits your business An app is a working part of your Opser workspace: it stores business records, gives people an interface to work with them, and can give agents tools to do the same work. Your team can use the screen, ask an agent, or combine both in one workflow. You can install an available app or describe a workflow and have an agent build an app for it. The apps offered to your workspace can change. These guides explain the system they share; the App Store and your workspace show what is available to you. ## People and agents work on the same records An app might track equipment, review requests, or coordinate a process specific to your business. Its interface presents those records as forms, lists, boards, or other views. Its agent tools expose supported actions, such as finding a record or updating its status. For example, you could open an equipment record and change its return date, or ask an agent to make that change. A well-built app puts both actions through the same business rules. The agent does not need to imitate mouse clicks when the app provides a tool for the task. An app's [skills](https://docs.opser.com/agents/skills/) explain its workflow and how to use its tools. Permissions decide which people and agents can use them. See [Inside an app](https://docs.opser.com/apps/anatomy/) for how these pieces fit together. ## Describe what you need Start with the workflow, not a feature list: > We lend equipment to staff. Build a place to request a checkout, approve it, and track returns. Requesters should see their own requests; coordinators should manage all checkouts. Let the agent find overdue items and prepare reminders. The agent can inspect existing apps before building so it can extend the right one or reuse an operation another app already provides. You review a draft with test data before installing the result into the workspace. [Build an internal app](https://docs.opser.com/capabilities/internal-apps/) walks through that process. Building must be enabled in your environment. ## Apps connect through explicit interfaces An app can offer an operation another app calls, emit an event when something changes, or send a notification to a person. Those are different capabilities with different purposes. A connection needs to be implemented and declared; installing two apps does not automatically join their workflows. Read [How apps work together](https://docs.opser.com/apps/connected/) to understand contracts, events, notifications, and live views. ## Your workspace decides what is available The sidebar reflects installed apps and your access. Installation, publication, and updates need the relevant permissions. An installed app can be available to one group and hidden from another. Use [Install & manage apps](https://docs.opser.com/apps/managing/) for the lifecycle and [Permissions](https://docs.opser.com/workspace/permissions/) for access. A separate customer website or portal has a different deployment boundary; see [external apps](https://docs.opser.com/capabilities/external-apps/). --- # Inside an app Understand the records, interface, agent tools, and access rules that make an app useful. Source: https://docs.opser.com/apps/anatomy/ ## One app, several surfaces An Opser app is more than a page in the sidebar. It brings together records, a human interface, and the capabilities it exposes to agents and other apps. Its manifest describes those surfaces so the platform can discover and govern them. Not every app needs every surface. A small reference app may only provide screens and reads. An operational app may also provide changes, events, notifications, integrations, and agent guidance. | Part | What it does | | --- | --- | | Records and rules | Define the information the app owns, its validation, and allowed changes | | Views and actions | Let people find records and carry out the workflow | | Agent tools | Let an agent perform named actions with structured inputs | | Skills | Explain when and how to use the app's capabilities | | Permissions and resources | Control access to actions and, where implemented, individual records | | Contracts | Offer named operations to other parts of the workspace | | Events | Announce changes to subscribing workflows | | Notifications | Bring a change or decision to a person's attention | ## Records belong to a business domain An app owns its data model and the rules around it. When an agent builds an app, it defines the records and relationships needed by that workflow. Updating a live app needs to preserve existing records as well as introduce the new behavior. Apps do not gain unrestricted access to each other's database tables. To reuse information another app owns, they call an operation that app exposes. This keeps the owning app's rules in the path. User-managed datasets have a separate [data and reporting](https://docs.opser.com/capabilities/data/) surface. ## Tools make the app usable by agents An agent tool is an action with a name, a description, and structured inputs. An equipment app could expose actions to find an asset, create a checkout request, or record a return. These are examples of a design, not a promised app catalog. The platform discovers the tools from the loaded app and checks access when they are listed and invoked. An action can also require approval. When someone talks to an agent, that person's access matters alongside the agent's: an agent never does more than the person talking to it may do, and access to an agent is not permission to every record. Ask the builder to make the human interface and agent tools use the same service rules. Review both paths: a working form does not prove the agent can complete the workflow. An app can also expose searchable primary records to [workspace search](https://docs.opser.com/workspace/search/). Include that behavior when you want people to find its records from the workspace's search control. ## Skills explain the workflow An app can provide instructions about its concepts, required inputs, and preferred sequence of actions. This helps the agent choose the right tool and interpret the result. Installing a skill does not grant the permissions that its tools need. For example, a checkout skill might explain that an asset must be available before a request can be approved, and that recording a return should close the active checkout. Read [Built-in skills](https://docs.opser.com/agents/skills/) for the difference between instructions and execution. ## Access follows the action and record Apps declare permissions, and can bind actions to resource rules for ownership, sharing, or other relationships. Access can therefore be narrower than the ability to open an app. A person who can view requests may still be unable to approve one. When reviewing a custom app, test with the intended roles and with someone who should not see the record. Include agent calls in that review. [Permissions & access groups](https://docs.opser.com/workspace/permissions/) explains the workspace controls. ## Build for the whole workflow Specify the records, screens, agent actions, access rules, notifications, and connections when you brief the agent. The builder's readiness checks inspect declared capabilities as well as the build. Then try the workflow yourself, including missing data and rejected actions, before installation. Continue with [connected apps](https://docs.opser.com/apps/connected/) or the [app building guide](https://docs.opser.com/capabilities/internal-apps/). --- # How apps work together Connect workflows through declared operations, events, and shared platform services. Source: https://docs.opser.com/apps/connected/ ## Shared context, explicit connections Opser brings apps into one workspace with a shared identity and permission system. Each app still owns its records and behavior. Apps work together by exposing capabilities and declaring the ones they use. That distinction matters when you ask an agent to connect workflows. Name the source, the trigger or request, the destination, and the result. The agent can inspect the available interfaces and identify anything that needs to be built. ## Contracts request an operation A contract is a named operation one app offers to another. A provider might offer “get equipment availability.” A requesting app declares that it consumes that operation, sends the required inputs, and gets a result. The platform checks the declared provider and consumer relationship. Resource rules and the authority under which the request runs also apply. An app cannot simply call an arbitrary operation in another app because both are installed. Use a contract when a workflow needs an answer or action now. If the provider is missing, unavailable, or denies access, the requesting workflow needs to handle that outcome. A useful custom app explains the problem instead of presenting an empty result as success. ## Events announce a change An event describes something that happened, such as an equipment return being recorded. The emitting app declares the event, and a receiving app declares its subscription and implements the response. Events let workflows react without making the original app perform every downstream step. A request system could react to a return by checking a waiting list. That connection must be implemented; an event name alone does not create the behavior. Delivery can be retried, so a receiving workflow must handle the same event more than once without duplicating its work. Events are delivered to the subscriptions active when they are emitted. A new subscription does not automatically replay the past, and a failed delivery is not a guarantee of eventual completion. Check the resulting records when a downstream action is missing. ## Notifications inform people A notification is a message for a person. An event is a signal for a workflow. The same business change may produce both, but they are not interchangeable. Apps can declare notification types that appear in **Settings → Notifications**, with bell and email preferences where supported. Turning off an email notification does not disable the underlying business event or automation. Read [Inbox & notifications](https://docs.opser.com/workspace/notifications/) for delivery preferences. ## Live views reuse read operations An app can explicitly expose a read operation for a dashboard or other composed view. Its input and output describe the data the view can use, and it keeps the app's own logic, so the view keeps working when the app changes its tables. The agent prefers such an operation when one exists. Without one, a dashboard can still read the tables of the apps you can open, read-only, the same way the agent's data tool does; it never shows an app you cannot open. See [Dashboards & live views](https://docs.opser.com/capabilities/dashboards/). ## External connections are a separate boundary Agent connections authorize an agent to use an external service. An app may instead declare its own integration for incoming or outgoing data, with separate setup and access requirements. Neither connection grants general access to every workspace record. For a connected workflow, verify the account, the allowed operations, who initiates the work, and where the result is stored. Read [Connect your tools](https://docs.opser.com/agents/integrations/) for agent connections. ## Brief the agent with an end-to-end example > When equipment is returned, check the waiting requests, identify the next eligible person, and notify the coordinator. Do not approve the next checkout automatically. Show me how a repeated event and a missing destination app are handled. Review the normal path, an unavailable dependency, denied access, and a repeated event. The connection is complete when the downstream behavior works with the intended permissions, not just when the original action succeeds. --- # Install & manage apps Keep track of what is installed, what is being built, and who can use it. Source: https://docs.opser.com/apps/managing/ ## Discover and install Open the **App Store** to see apps offered to your workspace. Review an app’s description and requirements, then use the installation controls if you have permission. Installation availability depends on the catalog and app requirements. Every plan includes unlimited installed apps. After installation, check **Settings → Apps** and the sidebar. An app can be installed without being visible to every user; access permissions determine who can open it. ## Installed apps and work in progress Settings → Apps separates the workspace’s app management from discovery in the store. Inspect installed apps, work being built, and operation history. A draft or preview is not the same as the version your team uses in production. **Your apps · Fictional data** Northstar has a customer portal and feedback board built for its workflows. These fictional examples do not describe a fixed app catalog. For agent-built apps, follow the [internal app](https://docs.opser.com/capabilities/internal-apps/) or [external app](https://docs.opser.com/capabilities/external-apps/) guide and review the publication result. ## Updates and permissions Apps update automatically: when a new version is published, it installs by itself and the people who manage apps get a notification. To update apps yourself instead, turn off **Update apps automatically** in **Settings → General**, under **Workspace**; each new version then arrives as an update notification for you to install. An app you customized never updates automatically, because its update has to be reviewed and merged with your changes. If an automatic update fails, you get an update notification to install it yourself. Before changing an app, understand the affected workflow and data. Verify key screens and agent tools after an update. Review grants for newly introduced capabilities rather than assuming every user should receive them. ## Removing an app Read the removal confirmation and understand the effect on its records, connected workflows, dashboards, and automations. Export or preserve information your team needs before a destructive removal. Do not treat uninstalling as a reversible way to hide an app from one user; adjust that user’s access instead. ## If an installation fails Inspect the reported operation error. Common causes include missing access, a required dependency, or an invalid build. Check [troubleshooting](https://docs.opser.com/help/troubleshooting/) and include the app name and error when asking for help. --- # Wiki pages and checklists Create, organize, and share collaborative Wiki pages, write checklists, and work safely with your agent. Source: https://docs.opser.com/apps/wiki/ ## Open Wiki Wiki keeps your team's knowledge in a tree of collaborative pages. Use it for instructions, process documentation, meeting notes, and checklists. Open **Wiki** from your workspace's apps. If it is missing, ask an admin to check installation and your access; available apps depend on your workspace. ## Create and organize pages Choose **New page**, enter a title, and write in the editor. Pages can contain other pages: use a page's add control in the tree, or the editor's page command, to create a subpage. Open a page from the tree to read or edit it. Use the page controls to move, duplicate, or favorite a page. Moving or duplicating a page includes its subpages. Move unwanted pages to **Trash**; restore them there if needed. Permanent deletion removes the page and its subpages for good. ## Write a checklist In the editor, type `/` to open the block menu and choose a checklist item. Write one step per item and click its checkbox to mark it complete. Combine checklists with headings and explanatory paragraphs to document a process. An agent can create a page with an initial Markdown body, including task-list syntax: ```markdown - [ ] Review the instructions - [ ] Confirm the owner - [x] Prepare the draft ``` The unchecked items are pending; the checked item is complete. Review the page in Wiki after creation. A checkbox records completion on that page; assigning work, deadlines, or notifications requires a separate supported workflow. ## Find and share pages Use Wiki search to find pages by title or body text. Favorite pages you revisit. Copy the page link to share it with a teammate who has access. A link opens the page but does not grant permission to view it. People can edit the same page collaboratively. Use page comments for discussion and inline comments for a passage. Resolve an inline thread when the discussion is finished. ## Ask your agent to work in Wiki > Create a Wiki page called Launch checklist under our Operations page. Include preparation steps as unchecked items and link me to the result. The agent can find, read, create, and organize pages using Wiki tools. `wiki_create_page` accepts an optional title, parent page, and initial Markdown body. Ask the agent to find the parent page first and use the returned page URL for the result. Before changing an existing page, the agent should read it. Replacing its body requires the latest revision and approval; if someone edits it meanwhile, the agent must read it again. Body replacement can leave existing inline comments without their text anchors, so review the replacement and affected comments carefully. Collaborator-visible comments and permanent deletion also require approval. ## Access and troubleshooting `wiki.view` allows reading and searching. `wiki.edit` allows editing content, favorites, and comments. `wiki.manage` allows creating, moving, duplicating, trashing, restoring, and permanently deleting pages. An agent also needs access to the Wiki app. An admin manages grants under [Settings → Permissions](https://docs.opser.com/workspace/permissions/). If a page or action is unavailable, check your access and whether the page is in Trash. Wiki tools need an initiating user for permission checks and attribution; an automation running without one cannot use them. See [Approvals and control](https://docs.opser.com/agents/approvals/) for agent action review. --- # Your workspace Get oriented, personalize your experience, and give your team the right access. Source: https://docs.opser.com/workspace/overview/ ## Find your way around The sidebar brings together your agents, installed apps, and workspace destinations. Use **Inbox** for platform notifications and **Automations** for automated work. An installed **Email** app has its own mail inbox; it is separate from the platform Inbox. Your account menu opens Settings and account actions. The settings navigation groups personal preferences, workspace administration, and developer tools. ## Personal settings These settings are about your own experience: - [Preferences](https://docs.opser.com/workspace/preferences/): appearance, language, and home page. - [Profile](https://docs.opser.com/workspace/profile/): account details and password. - [Notifications](https://docs.opser.com/workspace/notifications/): how you hear about workspace activity. - [Activity](https://docs.opser.com/workspace/activity/): what you did and what agents did for you. - [Context](https://docs.opser.com/agents/context/): information that helps your agents work with you. ## Workspace administration Administrators configure organization information, add users, and manage billing. Specific permissions can grant access to app management, usage reporting, storage, and access administration. | Destination | Guide | | --- | --- | | Organization | [Organization settings](https://docs.opser.com/workspace/organization/) | | Users | [Adding and managing teammates](https://docs.opser.com/workspace/users/) | | Agents | [Agents and who can use them](https://docs.opser.com/agents/overview/) | | Access | [Permissions and access groups](https://docs.opser.com/workspace/permissions/) | | Apps | [Managing installed apps](https://docs.opser.com/apps/managing/) | | Usage | [Understanding usage](https://docs.opser.com/billing/usage/) | | Billing | [Plans and subscriptions](https://docs.opser.com/billing/plans/) | | Data | [Workspace data and exports](https://docs.opser.com/workspace/data/) | ## When a setting is missing The navigation reflects your permissions. If you do not see a workspace setting or cannot open an app, ask an administrator to review your access. Refresh after permissions change. If the problem continues, use the [troubleshooting guide](https://docs.opser.com/help/troubleshooting/). ## Find a page or record Use [workspace search](https://docs.opser.com/workspace/search/) or **⌘ K / Ctrl K** to open destinations and find supported app records. Search respects your access and the capabilities each installed app exposes. --- # Find pages & records Use workspace search to navigate and find records from apps you can access. Source: https://docs.opser.com/workspace/search/ ## Open workspace search Use the search control in the Opser workspace or press **⌘ K** on macOS and **Ctrl K** on Windows and Linux. Search helps you open a page or find a record without walking through the sidebar. This is separate from the search on this documentation site. Workspace search uses your signed-in access. Docs search only reads public guides. ## Navigate to an app or setting Type the name of a page, app, or setting. The navigation results reflect destinations available to you. Select a result to open it, or close search with Escape to return to your current work. If a destination is missing, check whether the app is installed and whether your account has permission to open it. A different search term will not reveal a page you cannot access. ## Find business records The search can also ask installed apps for matching records. An app must expose its search capability, and results are filtered by access. You may see records from several apps in one search, but this does not mean every field or file in the workspace is indexed. Use a distinctive name or identifier. Open the result to inspect the authoritative record in its app. If an expected record is absent, check the app's own search and your record-level access. ## Continue with your agent You can also ask your agent to find a page or record, list an app's pages, or open a page for you. The agent checks that the page exists and that you can access it before opening it, and keeps the conversation beside the page so you can follow its work. Scheduled runs do not open pages on your screen. The search interface can offer to hand a question to the agent when you want investigation rather than navigation. Give the agent the source and the outcome you need. A record search finds candidates; the agent can use supported tools to compare them or complete a task. When building an app, include searchable primary records in its requirements. Read [Inside an app](https://docs.opser.com/apps/anatomy/) for the interface and tool capabilities that make an app usable across the workspace. --- # Themes & preferences Make Opser comfortable to use, from the color palette to the page you open first. Source: https://docs.opser.com/workspace/preferences/ ## Personal settings Open **Settings**. The Personal section lists **General**, **Appearance**, **Notifications**, and **Profile**. **General** is a short list in groups. **Basics** has your language and where Opser opens. **Your agent** has how it opens pages, whether the chat shows its steps, and your dictation words. **Phone** lists your connected phones, which you can sign out, and **Connect a phone** shows a single-use QR code that connects the Opser mobile app to your account. For people who manage apps, **Workspace** has whether apps update automatically for everyone. An agent’s voice is configured with that agent, in its **General** settings. The docs site has its own theme control in the header. Changing the docs theme does not change your Opser account preferences. ## Customize the appearance Open **Settings → Appearance**. **Look** has your color mode, palette, shape, font, and icon weight. **Layout**, on a computer or iPad, has density, the sidebar text and icon sizes, and **Collapse the sidebar in apps**, which gives an app more room when you open it; you can expand the sidebar again any time. Every change applies right away, so check both dense app views and conversation screens. **Reset** returns to the defaults. These choices affect your personal experience. They do not change another teammate’s preferred theme. ## Set your language Open **Settings → General** and choose **Language** under **Basics**: English, Italian, Spanish, German, or French. The language selection applies immediately in the supported platform interface. Separately provided apps may have different translation coverage. These docs are available in the same five languages. Use the language menu in the docs header to switch languages while staying on the same guide. The docs language is separate from your Opser account preference. ## Choose your home page Open **Settings → General** and use **Open Opser on** under **Basics** to pick from the destinations available to your account. This controls where you land when opening Opser. A destination must be available to you; changing the home page does not grant access to an app. ## Show the agent's steps Open **Settings → General** and find **Show its steps** under **Your agent**. It is off by default, so an agent's chat shows what the agent writes, as chat bubbles, with a short line saying what it is doing while it works. Turn it on to also see the tools, reasoning, plan, and sub-agents behind each reply, for checking how the agent works. The choice is yours alone and applies to the chat page, the side chat, and the mobile app. You can also ask an agent to switch it for you. See [what you see while the agent works](https://docs.opser.com/agents/conversations/#what-you-see-while-the-agent-works). ## Teach dictation your words Dictation already listens for your teammates' names, your agents, your apps, and your company's name. Open **Settings → General**, find **Dictation words** under **Your agent**, and choose **Edit** to add anything else it should spell right. Under **Words**, add names and terms you say, such as a customer or product, exactly as they should be written. Under **Fixes**, add a word dictation keeps getting wrong and what to write instead, for example **opzer** → **Opser**: every transcript is corrected, whole words only, in any capitalization. You can keep up to 100 words and 100 fixes, and remove any with its **X**. A fix changes that word everywhere you dictate, so avoid one for an ordinary word you also use. Your dictionary is yours alone. You can also tell your agent, for example "dictation keeps writing opzer, it's Opser", and it saves the fix for you. Meetings uses the same words and fixes for your own microphone; recordings that tell voices apart get your fixes. See [voice conversations](https://docs.opser.com/agents/voice/). ## If a preference does not stick Wait for the save to finish and check for an error message. Refresh the page once. For an unavailable home destination, ask an administrator to inspect your permissions or whether the app is still installed. --- # Profile & password Keep your account details recognizable and manage your sign-in password. Source: https://docs.opser.com/workspace/profile/ ## Update your profile Open **Settings → Profile**. Update your display name and use the avatar control to upload a profile image. Save the changes and check the result in the account interface. You can also ask your agent in chat. Attach a photo and say "use this as my profile picture", or ask it to change your display name. The agent saves the change the same way this page does, and the new picture shows in the sidebar straight away. Your email address is shown as account information. It is not editable through the same name field. Ask your workspace administrator for help if the address associated with your account needs attention. **Linked accounts** on the same page manages your Google sign-in link and a ChatGPT subscription connection that your agents can use for Codex models (see [models](https://docs.opser.com/agents/models/)). ## Change your password Use the password section on the Profile page. Enter your current password, a new password, and the confirmation, then submit the change. If the confirmation does not match or the current password is incorrect, correct the inputs and try again. Use a password unique to this account. Do not send it to an agent conversation or include it in a support request. ## Signing in for the first time An admin [invites you](https://docs.opser.com/workspace/users/) by email. Open the link, enter your name and choose your own password; nobody else sets it for you. ## Recover a forgotten password Use **Forgot password** on your workspace's sign-in page to request a reset email. Open the single-use link and choose a new password. If the link has expired or already been used, request another one. A successful request does not confirm whether an email address has an account. Sign-in can also require a verification code sent by email. Enter that code in the sign-in flow; never share it in a conversation. See [workspace access](https://docs.opser.com/start/access/). ## If you cannot sign in Confirm you are using the correct workspace address and account email. Ask your administrator to check whether your account exists and is active. Do not create a duplicate account to work around an access problem. See [troubleshooting](https://docs.opser.com/help/troubleshooting/) for information to include when requesting help. --- # Organization settings Set the shared identity and defaults that help your workspace stay consistent. Source: https://docs.opser.com/workspace/organization/ ## Open Organization Administrators can open **Settings → Organization**. Its tabs divide the page: **General** displays the organization identity and provides controls for the logo, timezone, and currency; **Company** holds the company details, **Templates** the reusable company templates and additional context, and **Payments** the business's Stripe account. The organization name is supplied by the workspace configuration and is not edited through the same form as the other fields. Contact the workspace operator if that identity needs to change. ## Set a recognizable logo Upload the correct organization logo and inspect the preview. Choose an image that remains clear at the small sizes used in the interface. ## Check timezone and currency Choose the timezone that reflects the organization’s operations and its default currency. Save the changes and review any workflow where those defaults matter. A default currency does not convert historical financial records or make mixed-currency totals comparable. A timezone default is also not a substitute for checking the timezone on an important schedule. ## Define templates Use Templates to define reusable documents, media, workflows, social posts, and other company outputs. Add content or examples, instructions, and optional reference files. Agents receive these templates for matching tasks. See [Templates](https://docs.opser.com/workspace/document-standards/). ## Add business context Use **Additional context** in **Settings → Organization → Templates** for information about the business that agents should understand. Organization context and personal context have different scopes; see [Context and memory](https://docs.opser.com/agents/context/). ## Review with your team Tell the relevant people when changing a shared default. Check [schedules](https://docs.opser.com/agents/automations/) and financial workflows if they rely on the affected setting. --- # Templates Reusable company templates for documents, media, workflows, social posts, and other outputs. Source: https://docs.opser.com/workspace/document-standards/ ## Create reusable company templates Open **Settings → Organization → Templates** to define reusable content, examples, instructions, and reference files for your business. Choose **Document**, **Media**, **Workflow**, **Social post**, or **Other**. Existing document templates remain available as Document templates. ## Add a template Administrators can add a name, a description of when to use the template, content or an example, and instructions. Reference files are optional. You can attach documents, images, video, audio, JSON, or YAML. For a LinkedIn launch post, choose Social post and put an example in Content or example: > Meet {{product}}. Built for {{audience}}. Learn more: {{url}} Use Instructions to explain the brand voice, required details, and how to replace the placeholders. A workflow template can describe the steps and expected result of a recurring process. Saving it does not run or schedule that process. ## Use and maintain templates Ask your agent to use the named template for a matching task. All company agents receive the template type, content, instructions, and reference file information. Agents can fetch an attached file with the storage tool. You can also ask your default agent, the one created with your account, to create or update a template. The platform tool provides `list_templates`, `set_template`, and `delete_template`. Editing requires organization permission; other agents can read templates. Existing template fields save automatically. Replace, download, or remove the reference file as needed. Review generated outputs and update obsolete templates. Changes guide future work. Use [skills](https://docs.opser.com/agents/skills/) for agent procedures and [context](https://docs.opser.com/agents/context/) for durable facts. Templates hold reusable examples and company output conventions. --- # Add & manage teammates Invite your team by email and give each person the role and apps they need. Source: https://docs.opser.com/workspace/users/ ## Before you invite someone Open **Settings → Members** with permission to invite people. Every [plan](https://docs.opser.com/billing/plans/) includes unlimited users, so you can invite as many people as you need. ## Invite people 1. Select **Invite**. 2. Type each email address and press Enter, or paste a list. 3. Choose their role. A **Member** uses the apps you give them, and can create their own agents and build apps (an admin installs them). An **Admin** also manages people, apps, settings and billing. Only admins can make someone an admin. 4. Choose their apps. **All apps** includes apps added later; turn it off to pick specific apps. 5. Send the invitations. You can only give access that you have yourself. Each person receives an email with a link to join. They enter their name and choose their own password, so nobody sets a password for them. The link expires after seven days. ## Manage pending invitations People you invite show as invited in the list until they join. Open someone's page to send the invitation again or to revoke it. Revoking removes the person, who never joined. ## Change access or remove someone Open a person's page and select **Permissions** to change their role and apps. When a role and apps aren't enough, open **Advanced permissions** to use access groups and individual permissions. Only admins install apps by default. To let someone install apps without making them an admin, turn on **Install, update and remove apps** in their advanced permissions. To remove someone, open their page and select **Remove from workspace**. They can no longer sign in, and you can invite them again later. Make an admin a member before removing them. For a departing teammate, also review the agents they own or can use, external accounts, and any automations that depend on them. The agents a person owns never do more than that person could. See [Permissions and access groups](https://docs.opser.com/workspace/permissions/) for how roles, groups and individual permissions combine. An employee or contact record in an app is separate from an Opser sign-in account. --- # Permissions & access groups Control what people and agents can use without giving everyone administrator access. Source: https://docs.opser.com/workspace/permissions/ ## How an agent's access works Every agent has an owner. An agent never does more than its owner could, and never more than the person talking to it may do in Opser. Changing a person's grants therefore changes what the agents they own can do, and what any agent can do for them. Giving someone access to an agent lets them use it; it does not let them do through the agent what they could not do themselves. Who may use an agent and what it may do are separate decisions. See [Give people access](https://docs.opser.com/agents/overview/#give-people-access). An action can check the agent, its owner, and the person making the request, as well as the target record's rules. Access to an agent does not automatically authorize every action the agent could perform. ## Review a person or agent Open **Settings → Access** if you have permission to manage access. Select the relevant person or agent and inspect their effective access. Grants can come from individual permissions and assigned access groups. **Access permissions · Fictional data** Maya is not an administrator. Her Customer success group grants portal access; billing management is not granted. Use the permission groups to find the relevant platform area or app. Some apps separate reading, collaboration, and management. Giving someone permission to read records does not necessarily let them configure the app. ## Use access groups Access groups collect permissions for a common responsibility. Create a group with a clear name and purpose, add the intended permissions, and assign the appropriate people or agents. For example, an operations group might grant access to specific task and purchasing workflows while leaving billing administration to administrators. Review membership whenever a person’s responsibility changes. Group changes affect the principals assigned to the group. Check effective access after removing a grant: another group or direct permission may still provide it. ## Administrator access Administrator status provides broad workspace authority, including settings such as organization management and billing. Use it for people who need to administer the workspace. Prefer focused permissions and groups for ordinary app work. ## Permissions are not approvals Permissions define available authority. [Approvals](https://docs.opser.com/agents/approvals/) decide whether an authorized agent action should wait for a person to review it. Approving an action cannot bypass a missing permission. App-level sharing and membership also matter. A mailbox, private chat channel, or shared document can have its own access rules in addition to platform permissions. ## Diagnose missing access Check the selected user or agent, direct grants, group membership, app installation, and any record-specific sharing. Refresh after a change and try a small read operation before repeating the original task. --- # Activity See what people and agents did in your workspace, and who did it. Source: https://docs.opser.com/workspace/activity/ ## See what happened in your workspace Opser keeps an activity log with one entry for each thing someone did: a record created or changed in an app, a setting or permission changed, a sign-in, a conversation started, an action an agent took for someone, an automation that ran. Opening pages, searching, and reading records are not recorded. Only actions that changed or sent something are. You read the log by asking your agent. Each entry records who acted and what they did, the app or conversation it happened in, whom an agent acted for, how it came in (web, mobile app, chat, or automation), and whether it failed or was refused. ## Who sees what Everyone sees their own activity, including what agents did for them. People with the **View everyone's activity in the workspace** permission can ask their agent about the whole workspace; administrators have it by default. Grant it on the [permissions page](https://docs.opser.com/workspace/permissions/) to someone who needs to review the workspace without being an administrator. They see what others did, in which app and to which record, but not the record's own words, such as an email's subject, a note's title or a conversation's title; those appear only in each person's own activity. ## How entries are recorded Opser records each entry itself, at the moment it handles the action. The app that performed the action never writes its own entry, so an app cannot leave an action out or attribute it to someone else. When an agent acts, Opser records the agent and checks the person it says it acted for: someone in that conversation, the person who set up the automation, or the owner of a default agent. Entries cannot be edited or deleted. A refused sign-in for your account appears in your own log, so you can spot attempts you did not make. ## Ask your agent Your agent can read your activity. Ask "what did I change last week?", "who updated this order?", or "did the Monday automation run?". It reads with your access, so it sees only what you are allowed to see. The default [weekly review](https://docs.opser.com/agents/automations/) uses the same log to suggest improvements based on how you actually work. ## How long entries are kept Entries are kept for one year and then removed. When an account is deleted, the person is removed from every entry that names them: what happened and when remain, but not who. --- # Security & data protection How Opser keeps your workspace isolated, your sign-in protected, and your data under your control. Source: https://docs.opser.com/workspace/security/ ## Your workspace is isolated Each Opser workspace is a separate tenant. Your business records, files, users, and agents belong to your workspace, and the platform keeps them separated from every other workspace at the database level — not just in the interface. Access to your data always runs through your workspace's own permissions. Your workspace has a configured hosting region. Connected services and model providers may process task content elsewhere; the hosting region is not a guarantee that every provider processes data in the same location. Confirm any data-location requirements with Opser before adding sensitive information. ## Sign-in is protected Accounts sign in with an email and password, and Opser adds a verification step: after the password, you enter a one-time code sent to your account email. Passwords are stored only as a secure one-way hash, never in plain text, so they cannot be read back — which is why a forgotten password is [reset](https://docs.opser.com/workspace/profile/), not retrieved. If someone leaves your team, remove their account in [Add & manage teammates](https://docs.opser.com/workspace/users/). A password reset ends that account's existing sessions. ## Agents act within limits you set An agent can only use the apps, records, and connected accounts its access allows. Two independent controls keep that boundary in place: - **Permissions** decide what an agent and a person can reach. Grant access per person or agent, or with reusable [access groups](https://docs.opser.com/workspace/permissions/), instead of making everyone an administrator. - **Approvals** decide which actions run on their own and which pause for your review. Sending email, deleting records, and changing settings ask first by default. See [approvals & control](https://docs.opser.com/agents/approvals/). A permission is not the same as an approval: approving one action never grants standing access to a restricted app, mailbox, or record. ## Connected accounts and secrets When you connect an outside account — a mailbox, a calendar, or another service — check the selected agent and the access shown in its connection settings. How authorization is stored depends on the integration; some connections are managed by an integration provider. Connecting an account does not give every agent in your workspace access to it. Disconnect an account at any time from [Connect your tools](https://docs.opser.com/agents/integrations/). For values an app needs to keep, such as an API key, an administrator can store them in the workspace **Vault**, kept apart from ordinary records. Never paste a password, verification code, or API key into a conversation; connect accounts through their proper setup flow instead. ## What agents send to model providers Agents use large language models and, when you enable them, services such as web search or media generation to do their work. The content of a task is processed by the provider running that model or service. Give an agent the context a task needs, and use permissions and approvals to keep sensitive actions under review. Web research keeps its findings linked to their [sources](https://docs.opser.com/capabilities/research/) so you can check them. ## Managing your data Administrators can review every app's records and the workspace's files, and export them, in [Data & exports](https://docs.opser.com/workspace/data/). Exporting or deleting your workspace's data is a deliberate action — canceling a subscription does not automatically export or erase your records. Plan an export before you make an irreversible billing change, and see [subscriptions & payments](https://docs.opser.com/billing/subscriptions/) for what a cancellation does and does not do. ## Reporting a concern If you believe an account is compromised or you have a security question, [contact Opser](https://opser.com/contact) with the workspace address and what you observed. Do not include passwords, verification codes, or reset links in the report. --- # Inbox & notifications Keep track of workspace activity and choose the notifications you receive. Source: https://docs.opser.com/workspace/notifications/ ## Use the platform Inbox The platform Inbox brings together notifications from Opser and installed apps. Open a notification to inspect its details and follow its link to the relevant work. Use read-state controls to keep track of what you have reviewed: a row’s menu can mark it as read or unread, and marking a grouped notification read also clears its repeats. Workspace notifications are separate from messages stored in a connected email account or an installed messaging app. ## Choose notification preferences Open **Settings → Notifications**. Preferences are grouped by platform and app notification types. The available types depend on installed apps and what they declare. The page provides Inbox, Push, and Email controls for supported types. Push sends alerts to a phone with the Opser mobile app when the workspace supports mobile push and you allow notifications on the device; an installed app’s activity, such as chat messages, can reach your phone even for types you keep out of the Inbox. Email notifications depend on the corresponding Inbox notification being enabled; the interface reflects that relationship. Delivery also depends on the workspace’s email configuration. ## Make notifications useful Keep notifications on for work that requires your action, such as approvals and assigned work. Reduce low-value notifications by type rather than ignoring the whole Inbox. An installed app may also offer its own notification controls. Check the app’s settings when a preference concerns a particular conversation or record. The **Emails from Opser** section separately controls getting-started tips, weekly reviews, and return reminders. These optional-email preferences apply across your workspaces, with at most two optional emails per week and at least 48 hours between them. Account, security, and app notification emails follow their own controls. If email preferences are temporarily unavailable, your saved choices remain unchanged; retry when the service is available. ## If a notification is missing Check the relevant preference, your access to the underlying record, and whether the source action actually completed. For email delivery, check the account address and spam folder, then ask your administrator to inspect delivery configuration if needed. --- # Data & exports See every app's tables and the workspace's files, read-only, and download or export them. Source: https://docs.opser.com/workspace/data/ ## What Data shows Administrators can open **Settings → Data** to see everything the workspace stores, read-only. **Tables** lists every app's tables, with the app each belongs to and how many rows it holds. Open a table to search and sort its rows, see what its columns hold, or open one record with every field. **Files** shows how much of your plan's storage is in use and which app's folders use it, down to each file, which you can preview and download. Nothing on this page changes data. To add, edit or remove a record or a file, use the app it belongs to, or ask your agent. Columns that hold secrets, such as share-link tokens and passwords, read as hidden on the page and in every download. Your agent's own working files are in its [Files](https://docs.opser.com/agents/files/) area. ## Download and export **Download CSV** on a table saves all of its rows. **Export all** builds one ZIP in the background: a CSV for every table, a description of their columns, and the workspace's files when they total 2 GB or less. Past that, the ZIP lists the files instead and you download them from **Files**. You get a notification when the export is ready, and it stays on the page for 7 days. A new export replaces the last one. ## Plan allowances Your plan includes a storage allowance. If uploads or generated files fail at a limit, review usage and decide what to retain or whether to change the plan. Credits and storage are separate allowances; buying credits does not itself add storage. ## Before removing data Check which app or record references a file and whether it must be retained. Remove content through the app that owns it, using its archive or trash action when that is the intended workflow. Permanent deletion can affect links and records that still refer to the content. For access changes, use [Permissions](https://docs.opser.com/workspace/permissions/) rather than deleting records to hide them from a person. --- # Plans & pricing Compare the included workspace allowances and find the right plan for your team. Source: https://docs.opser.com/billing/plans/ ## Fixed plans These are the list prices and included allowances represented by the current platform. Check **Settings → Billing** and the checkout summary for the offer available to your workspace, applicable taxes, and final payment amount. | Plan | Price | Credits per month | Storage | | --- | --- | --- | --- | | Free | $0 | 500 | 2 GB | | Growth | $49 / month | 25,000 | 100 GB | Prices above are in USD. Growth is billed monthly. ## Embedded Embedded is a negotiated plan that includes a forward-deployed engineer. Credits, storage, payment terms, and billing interval depend on the agreement for your workspace. Use the plan details shown in Billing and your agreement rather than applying the fixed-plan table to Embedded. ## What every plan includes Every plan includes unlimited users, agents, and installed apps. Plans differ only in monthly credits and storage. **Storage** limits file writes across the relevant workspace storage paths. ## Credits and renewal Plan credits refill to the monthly quota. Unused plan credits do not roll over. Credits are not sold separately from a plan. On Growth and Embedded contracts billed through Stripe in USD, an administrator can turn on [pay as you go](https://docs.opser.com/billing/usage/): agents keep running past the plan at $0.002 per credit, up to a monthly cap (Embedded can run without one), billed with the next invoice. Extra credits, such as credits granted by support or bought before credit packs were retired, are tracked separately, do not expire, and are used after the plan balance is exhausted. A credit is a unit of usage value, not a promise of one message or one task. Different models and operations consume different amounts. See [Usage and credits](https://docs.opser.com/billing/usage/). Existing Free workspaces keep their current credit balance until their next monthly renewal. At that renewal, the plan balance resets to 500 credits; unused plan credits do not roll over. Renewals follow the workspace’s monthly billing anniversary. ## Change your plan An administrator can open **Settings → Billing** to inspect the current plan and available subscription controls. See [Subscriptions and payments](https://docs.opser.com/billing/subscriptions/) before changing or cancelling a subscription. The public [pricing page](https://opser.com/pricing) provides the current commercial overview. --- # Usage & credits Understand where credits go and how to investigate a change in your balance. Source: https://docs.opser.com/billing/usage/ ## Credits are shared workspace usage Credits represent the usage value available to your workspace. One credit is worth $0.002 of usage value, so 500 credits are $1. The number of credits a task consumes depends on the models and operations it uses, rather than simply the number of messages you send. Model work, media generation, browser research, and other metered capabilities can have different costs. An app tool marked as free does not make the agent’s surrounding model work free. ## Two credit balances Plan credits are the allowance included in your subscription. They refill to the plan quota at the applicable monthly cycle and unused credits do not carry forward. Extra credits are a separate persistent balance, such as credits granted by support or bought before credit packs were retired. They are consumed after plan credits run out and do not expire. Credits are not sold separately from a plan; on Growth and Embedded, pay as you go covers usage past the plan (see below). ## Inspect usage Open **Settings → Usage** with the required usage-reporting permission. It is one page. Administrators see **Credits** first: the credits available and how much of the plan's monthly allowance is used. Everyone with the permission sees **Credits used**: select the reporting period and agent filter to focus on the work you are investigating, and break the total down by model, tool, or agent. Administrators also see the **Credit ledger** below it, every transaction with the balance after each, to understand balance changes. **Usage & credits · Fictional data** Example balance: 2,400 credits = 2,000 plan credits + 400 pack credits. This month’s example usage: 720 for models and 280 for metered tools. These are fictional balances, not plan allowances or prices. For a quick check, the account menu shows **Monthly usage** with the share of the plan’s monthly credits used. Its breakdown lists when the allowance resets, the plan credits left this cycle, any extra credits, and a **Manage usage** shortcut to the full report. The row appears with the same usage-reporting permission. The percentage uses the same colors as the Usage page: amber from 75% and red from 90%. Extra credits do not change plan usage. Once the plan reaches 100%, the menu shows **Using extra credits** and the extra balance left until those credits run out or the plan refills. The low-credit banner stays hidden while extra credits are available and returns when all credits run out. Credits becoming available again resets a previous dismissal; dismissing a low-credit warning does not hide a later out-of-credits warning. A busy automation or a media-heavy task can consume more than a short text conversation. Inspect the underlying conversation or run history when a total is unexpected. ## Credit alerts Administrators are alerted by email and in the Inbox as credits are used. In the **Credit alerts** card on **Settings → Billing** (on **Settings → Usage** in the mobile app, which has no Billing page), an administrator can set: - **Usage alerts**: an alert each time usage crosses one of these thresholds, as a share of the plan's monthly credits. The defaults are 75% and 90%; a workspace can keep up to five, from 1% to 99%, or none. - **Out of credits alert**: an alert when credits run out and agents pause. It is on unless turned off. While pay as you go covers usage, administrators instead hear when it takes over and when it reaches its cap. Each alert goes out once per threshold per monthly cycle. Each administrator can still turn off its email in their notification settings. ## Understand renewals For card-billed subscriptions, renewal credits depend on a successful monthly payment. Free and negotiated plans use the cycle appropriate to their configuration. Use the next refill and billing dates shown in your workspace rather than assuming every plan resets on the first day of the calendar month. ## When credits run out New metered work can be blocked when there is no available balance. Check whether the plan is due to refill, whether payment failed, whether a different plan is appropriate, and, on Growth or Embedded, whether pay as you go is on. Storage limits are separate from credit balance. See [Subscriptions and payments](https://docs.opser.com/billing/subscriptions/) for billing issues and [Plans](https://docs.opser.com/billing/plans/) for included allowances. ## Pay as you go On Growth and on Embedded contracts billed through Stripe in USD, pay as you go keeps agents running after the plan credits run out. It is off until an administrator turns it on in the **Pay as you go** card on **Settings → Billing**, or from the out-of-credits card in a chat. Where it can't be turned on yet, the card offers the step that allows it: the plans on Free, card payment setup for an Embedded contract, or the payment method after a failed payment. While it is on, usage past the plan costs the same $0.002 per credit. That month's extra usage is billed in whole credits with the next monthly Growth invoice. Once that invoice is paid, the credits it covered are back in the balance. On Growth, pay as you go always has a monthly cap: by default 1,000,000 credits ($2,000), and an administrator can set a lower one. An Embedded contract can set a cap or turn it off and run without one. When the month's extra usage reaches the cap, work stops as it does when credits run out, until the cap is raised or the plan refills. Administrators are notified when the plan credits run out and pay as you go takes over, and again when it reaches the cap. Turning it off stops new extra usage; what was already used is still billed. Pay as you go needs a monthly subscription billed through Stripe in USD whose last payment went through. If a payment fails, extra usage pauses until it is paid. If the subscription ends, any extra usage not yet billed goes on a final invoice. --- # Subscriptions & payments Manage the workspace’s plan, payment method, and invoices. Source: https://docs.opser.com/billing/subscriptions/ ## Open Billing Administrators can open **Settings → Billing**. Its **Plan** tab shows the current plan, billing interval, renewal or cancellation date, the next invoice, [pay as you go](https://docs.opser.com/billing/usage/), and the credit alerts; its **History** tab shows the payment history for your workspace. The credits themselves and what used them are on **Settings → Usage**. Some environments do not have self-service billing configured. Negotiated or operator-managed plans can have different controls from card subscriptions. If a control is unavailable, follow the contact or management path shown in the interface. ## Subscribe or change a plan To move from Free to Growth, use the plan selection flow and review the checkout details before paying. Confirm the plan, currency, taxes, and payment amount. The workspace’s effective entitlement should be checked after the successful checkout and billing update. Growth is billed monthly. With pay as you go on, the monthly invoice also carries the previous month's extra usage. Embedded is arranged by agreement rather than through checkout. To change an existing subscription, use the billing-management control or contact support. Do not assume a plan change is complete solely because you clicked the selection button. Return to Billing and confirm the resulting plan. ## Manage payment details Use the billing-management control when available to open the payment provider’s portal. Manage the supported payment methods and subscription actions there. The Billing page also shows payment history and links to available payment documents. ## Cancellation Check the cancellation date shown in Billing. A subscription scheduled to cancel can remain active until the end of its paid period. Once cancellation takes effect, the workspace falls back to the applicable default plan. Before downgrading, compare your current storage use with the new plan’s storage and check whether its monthly credits cover your usage. Pay-as-you-go usage not yet billed goes on a final invoice when the subscription ends, and pay as you go turns off. Do not assume cancellation automatically exports or deletes your business records. ## Failed or delayed payments Check for a failed-payment state, update the payment method if needed, and inspect the provider’s result. A failed card renewal can prevent a fresh credit grant and pauses pay as you go until it is paid. If a successful payment has not appeared, collect the payment reference and contact support instead of repeatedly purchasing the same item. --- # Use docs with an agent Search the guides, copy a complete page, or read the documentation as Markdown. Source: https://docs.opser.com/help/search/ ## Ask your Opser agent Ask your agent how to use Opser—for example, “How do I set up a weekly automation?” or “Where can I change approval settings?” The agent can search and read these guides directly and include links to the relevant pages. You do not need to connect an app or configure a web-search service. The guides explain how the product works. Your agent checks your workspace separately when the answer depends on your installed apps, permissions, connections, or current settings. The agent keeps a short-lived copy of the public guides. If the docs site is temporarily unavailable, it can use its last successfully fetched copy and tell you it may be outdated. If it has no copy yet, it reports that it cannot read the docs instead of inventing instructions. ## Find the right guide Use **Search docs**, **⌘ K** on macOS, or **Ctrl K** on Windows and Linux. Search covers the published article text and headings. Try “persistent files,” “built-in tools,” “app events,” or “credit rollover.” Use the section filters to narrow the results. The arrow keys move through matches, Enter opens one, and Escape closes search. Section results take you directly to the relevant heading. ## Copy a complete page Choose **Copy page** at the top of a guide. It copies the title, description, source link, and full article as Markdown. Links are absolute, so an agent can follow them after you paste the text into a conversation. The copied text contains the guide itself, without navigation menus or search controls. If clipboard access is unavailable, choose **Markdown** and select the text there. ## Read the docs without the interface Every article has a **Markdown** link. You can give that URL directly to an agent that can fetch web content; no Opser account or JavaScript is required to read it. The footer also provides **llms.txt**, an index linking to every public guide, and **All docs as text**, the complete documentation in one text file. Start with the index when an agent should choose relevant pages. Use the complete file when you want to supply the whole handbook, allowing for the agent's context limit. For example, ask an agent to read the documentation index, select the guides about persistent files and scripts, and explain how to reuse an analysis next week. These exports document the public product; they do not connect the agent to your workspace. ## Search and reading boundaries Search runs against a static documentation index. It does not search private workspace records or conversations, and it does not send your question to an AI service. JavaScript is needed for interactive search and copying. The articles, Markdown files, navigation, and table of contents remain readable without it. If search fails to load, retry or browse the relevant section. --- # Troubleshooting Find the cause of common problems before repeating a task or changing configuration. Source: https://docs.opser.com/help/troubleshooting/ ## An app or setting is missing Check that you are in the correct workspace and signed in as the intended user. Ask an administrator to verify the app is installed and inspect your effective permissions, including access groups and app-specific sharing. Refresh after access changes. A hidden setting often reflects permissions rather than a broken page. ## The agent cannot complete a task Ask the agent what stopped it, or turn on **Show the agent's steps** in **Settings → General** to read the latest tool result. Then check: - Is an [approval](https://docs.opser.com/agents/approvals/) waiting for a decision? - Does the selected agent have the required [permissions](https://docs.opser.com/workspace/permissions/)? - Is the relevant [integration](https://docs.opser.com/agents/integrations/) connected to the right account? - Did the source file upload successfully? - Are [credits and plan allowances](https://docs.opser.com/billing/plans/) available? Correct the specific missing dependency, then retry a small step. Changing models does not fix a missing permission or disconnected account. ## A change may have completed twice After a network error, inspect the target record before repeating a write. A browser interruption does not prove that the server cancelled the operation. Search for an existing task, order, invoice, or message before creating another. ## A scheduled run failed Open automation history and inspect the run. Check timezone, agent access, connection state, credits, and approvals. Review the existing schedule before creating a replacement that could run in parallel. ## A file cannot be opened or saved Check the upload result, file format, access to the containing app or folder, and available storage. For a generated file, open its file card in the chat, or turn on the agent's steps to inspect the tool result. Preserve the original when asking the agent to repair or transform a complex file. ## A payment is not reflected Inspect Billing and the payment provider’s status. Record the payment reference and contact support if the transaction succeeded but your workspace has not updated. Avoid repeated purchases while the original payment is unresolved. ## Get help Use the [support guide](https://docs.opser.com/help/support/) to include enough context for someone to reproduce the problem without exposing credentials or unrelated private records. --- # Get help Make a support request easy to understand and fast to investigate. Source: https://docs.opser.com/help/support/ ## Try a quick check first Many problems have a fast answer. Check [Troubleshooting](https://docs.opser.com/help/troubleshooting/) for common causes such as a disconnected account, a missing permission, or an [empty credit balance](https://docs.opser.com/billing/usage/). If a workspace-wide notice is showing at the top of Opser, a known issue may already be under investigation. ## Start with a clear description When **Support** appears below App Store in your sidebar, open it and choose **New ticket**. Describe the problem and optionally attach screenshots. This page works without installing Chat and does not spend AI credits. Tickets are private to you and the Opser team. You can also ask your default agent, the one created with your account, to open a ticket, find an existing one, read replies or send a follow-up. Review and approve a new ticket or reply before the agent sends it. Other agents cannot access your private tickets; use the Support page instead. If other people can use your default agent, they see its chat, including any ticket you read there, so use the Support page for anything you want to keep to yourself. Model usage still follows your workspace billing. Return to the conversation to read the team's reply, add details, resolve the ticket or reopen it. Notification preferences control alerts, and an unread team reply can trigger an email reminder. If Support is not available in your workspace, use the [Opser contact page](https://opser.com/contact) or your agreed workspace support channel. Explain what you were trying to do, what you expected, and what happened instead. Include the workspace address, the affected app or agent, the approximate time and timezone, and the visible error message. Mention whether the problem affects one user or several. ## Add useful evidence A short sequence of steps is often more useful than a large log. Include a record or conversation link when appropriate for the support channel. For billing problems, provide the payment reference rather than card details. Remove passwords, API keys, session tokens, and unrelated private information from screenshots or copied messages. Never provide your account password, a verification code, or a reset link to diagnose an issue. ## Improve an agent's answers If an agent's response was unhelpful, use the response feedback control on that message to mark it and add an optional note. This is separate from a support request: it helps tune future answers rather than opening a ticket. For a repeatable improvement, set the agent's [context](https://docs.opser.com/agents/context/) or a [skill](https://docs.opser.com/agents/skills/) so the next task starts from better instructions. Agents can also report gaps in Opser itself to the Opser product team on their own, such as a tool they needed that does not exist, a tool that misbehaved, or one whose results were unclear. These reports describe the gap generically, without personal data, secrets or business records, and you are not notified when one is sent. Nothing changes automatically because of a report, and it is not a support request: for help with your own problem, open a ticket as described above. ## Suggest a docs improvement If a guide is unclear, include the page URL and the step that confused you, and tell us what you saw in the interface so the guide can be corrected against the product. For immediate checks while you wait, see [Troubleshooting](https://docs.opser.com/help/troubleshooting/). --- # Glossary The words you will see across Opser, explained in everyday terms. Source: https://docs.opser.com/help/glossary/ ## People and agents **Workspace:** your organization’s Opser environment, with its users, apps, records, agents, and settings. **Default agent:** the first agent created with your user account. Like any agent, you can give other people access to it. **Specialist agent:** an additional agent you create for a particular role or kind of work. Only you use it until you give other people access. **Agent access:** the people who can use an agent besides its owner, who edits its settings. Everyone with access uses the agent together: the same chat, automations, files, memory, and connected accounts. An agent never does more than its owner could. **Access group:** a reusable collection of permissions assigned to people or agents. ## Work and capabilities **Chat:** an agent's one ongoing conversation, shared by everyone who can use it, including messages, questions, files, and results. It never resets. **Compaction:** how an agent keeps a long chat workable. It summarizes earlier messages, keeps the latest ones word for word, and looks up older details when it needs them. Nothing is deleted. **Steps:** the tools, reasoning, plan, and sub-agents behind an agent's reply. The chat hides them unless you turn on **Show the agent's steps** in **Settings → General**. **Tool:** an operation an agent can perform, such as reading a file or updating a record. **Skill:** instructions that help an agent approach a particular kind of work. **Approval:** a review point before a proposed agent action runs. It does not replace permissions. **Automation:** work triggered by a supported event or schedule. Its results show in the agent's chat. **Artifact:** a file or other output produced during a task, such as a workbook or slide deck. ## Apps and data **App:** a workspace tool with its own interface and supported data operations. You may also see the technical term “module” in operation details. **Internal app:** an app used within the Opser workspace. **External app:** a separate web experience, such as a site or portal, built through Opser’s external app capability. **Integration:** an authorized connection to an external service or account. **Draft:** work being built or reviewed before publication. A preview is not necessarily the published version. **Contract:** a declared operation one app offers and another app is allowed to request. **Event:** a signal that something happened, delivered to a declared subscribing workflow. **Notification:** a message bringing activity to a person's attention, separate from a workflow event. **Agent workspace:** the persistent filesystem belonging to one agent, used for inputs, scripts, and results from one task to the next. **Document standard:** an organization's instructions and optional reference file for a recurring document format. ## Billing **Credit:** a unit of usage value. A task’s cost depends on the models and operations it uses. **Plan credits:** the recurring allowance included with a workspace plan. **Extra credits:** a separate balance that does not expire, used after plan credits, such as credits granted by support.