In the setup builder, select Website actions and supply the public site name if you know it. Browser assistant is selected with it because the browser environment and permissions need review. Describe the intended change in the inquiry notes.
Offer 04 / Website actions
Website action workflows need a clear stop.
Moxby discusses browser task workflows for teams carrying out a bounded action on a named website. Define what should change and where a person reviews it. A request to prepare a form is not permission to submit it.
Inquiry basisIndividual scope per requested website action, subject to permission and feasibility review. No published rate or binding quote. Any later commercial proposal uses USD. There is no online payment.
Moxby / Austin, Texas, United States
A target website is a question to assess, not a supported integration merely because it is named in an inquiry.
The offer / A specific page action
Website actions
Start with the website action you need. Name the public site and describe the page's job, such as preparing a draft in an authorised work form. Explain what the person should see before deciding whether to continue.
This is the action-scoping side of the Moxby browser assistant. It is not a claim that every website can be automated. Website permission and technical feasibility are separate checks, and a positive answer to one does not settle the other.
The offer suits work whose beginning and stopping point can be described. If the instruction is “finish whatever appears,” narrow it. A bounded request gives a reviewer something to evaluate without granting permission to improvise through an unfamiliar page.
- Target
- A website name or public URL, with a plain-language description of the relevant page.
- Permitted action
- A stated change within the visitor's authority and the website's applicable rules.
- Review point
- The state a person inspects before any separately authorised commitment.
- Stop condition
- The expected end of the task, plus conditions that require a pause rather than a guessed next step.
- Price basis
- Individual scope after permission and feasibility review. Counting clicks is not a quote.
01 / Define the action
Replace “handle the website” with a bounded request.
The site name comes first. The desired change follows.
Use the public name or public address of the website in your inquiry. A private session link can expose information and may not tell another person anything about the task. Explain the page type instead: a work form, a draft editor or a review screen.
Describe the starting state the person recognises. Is the correct page already open? Has the person selected the relevant record? Are they working in a draft or an active published item? These distinctions matter more than the location of a button in a screenshot.
Next, state the intended difference between the starting page and the review page. “Place the approved text into the draft description field, then stop for inspection” is a bounded request. “Update everything” is not.
Do not send the approved text if it contains private information. An invented sentence with the same structure can explain the request. If a local preparation step produces that text, keep its input and external-processing boundary in a separate Local workflows description.
Your website choice in the option sheet is visitor-supplied information for review. The builder does not fetch the address or open the site. A named example below explains how to write the request; it is not a compatibility claim.
General work-form scope / Review before commitment
- Named target
- The visitor supplies the actual website name. Do not infer a supported target from this generic work-form example.
- Starting state
- A person has opened the intended draft form and identified the correct item under an account they are authorised to use.
- Requested change
- Prepare a proposed description in the specified draft field using already approved source text. Leave unrelated fields alone.
- Human review
- Compare the proposed field value with the approved source, and verify that the target is still the intended draft.
- Normal stop
- End before submission or publication. A later commitment is not included in the preparation request.
- Unexpected stop
- Pause if the field is missing, the target is unclear or a page message suggests that a change may already have been saved.
02 / Layout and page state
A familiar button can belong to a different action.
A request should explain what a field means, not just where it sat when someone last used the page.
Website action workflows depend on a page controlled by someone else.
A website can move a field, change a label or insert an intermediate screen. Different permissions can also produce different controls for different people. A sequence based only on appearance can reach the wrong action without looking obviously broken.
Describe the expected page state in terms of the work. The requested field should belong to the intended draft, not merely be the first large text box on the page. An unexpected dialog or missing control is a reason to stop and inspect, not evidence that the nearest alternative is correct.
A website change may require the requested scope to be reviewed again. Moxby does not promise universal compatibility or continued operation against every future layout. The Browser assistant offer explains why the environment and access boundary belong in the same discussion.
03 / Ambiguous outcomes
An uncertain result is not a reason to click again.
A slow page can leave you unsure whether an action happened. Repeating it can make the uncertainty worse.
Separate “the page did not show what I expected” from “nothing happened.” A website may accept a change before its confirmation appears. Automatically repeating the action could create a duplicate or overwrite an intervening change.
The stopping condition needs to cover this uncertainty. In the draft-preparation example, a message that suggests the site saved something unexpectedly calls for inspection. It does not authorise another attempt, a compensating edit or a claim that the task succeeded.
Ask what evidence a person can use to resolve the state. The answer may be a website-provided record view or a visible draft state, subject to the site's rules. It cannot be a success badge invented by the assistant. If there is no reliable way to tell, the action may not be suitable for the requested workflow.
04 / Permitted use
Access to a page is not unlimited permission.
Use the inquiry to identify what you are authorised to do and any website rules that limit the request. Do not share passwords, session cookies or account recovery details. Moxby does not need them to understand an initial workflow description.
Requests must respect access controls and other people's information. A visible page is not permission to collect personal records or bypass a site's restrictions. If your organisation needs to approve browser assistance, make that dependency explicit before discussing execution.
A
Authority to act
Identify whether the person using the website has authority for the proposed change. An account shared informally across a team does not settle who may approve the action or process the underlying information.
B
Website rules
Check the site's applicable terms and permission requirements. Technical feasibility is not an exception to those rules. Moxby does not offer this page as a way around login controls or anti-abuse measures.
C
Irreversible effects
Flag publication, deletion and any other commitment that is difficult to undo. Do not treat an apparent confirmation screen as proof that a safe reversal exists. A safer initial scope may end at a draft instead.
D
Human responsibility
Name the role that checks the target and approves any next step. The person may use a shared task for context, but a task assignment does not by itself authorise a website action.
05 / From request to scope
Check the boundary before agreeing the work.
- 01
Name the target and change
- 02
Identify the review state
Say what the person should inspect before proceeding. Include the intended target item as well as the proposed field value. A correct value placed into the wrong item is still an incorrect action.
- 03
Resolve feasibility questions
The requested environment and website permission need confirmation. A changed page layout, unavailable review state or ambiguous result may require a narrower request. This step does not imply an acceptance or response deadline.
- 04
Keep the agreed scope explicit
Any later proposal should distinguish the action from its surrounding preparation, with commercial terms in USD. Sending the form is not an order. The request process explains what an initial inquiry does and does not establish.
Buyer questions
Some actions should stay with the person.
The review boundary is useful only if it gives someone a real opportunity to decide.
Does naming a website confirm support?
No. The target field is part of your request, not a compatibility checker. Moxby does not fetch the site through the configurator or promise that the requested action is available. Permission and feasibility remain open until reviewed.
Can the workflow make a final commitment?
Do not infer that from the examples. They deliberately stop before submission or publication. If a final commitment is essential, describe its consequences and authorisation requirements explicitly. This offer does not promise unattended or irreversible actions.
What if a website saves changes automatically?
Then “fill the field but do not submit” may already cross an action boundary. Say that the site saves while editing if you know it does. The review point may need to occur before changing the page at all. A familiar draft interface is not evidence of a harmless temporary state.
Can the team track the reason for the action?
Discuss the associated conversation and document through the Team workspace offer. That is a separate shared-context request; it does not establish automatic website synchronisation or permission to act on behalf of everyone in the workspace.
Your action boundary
Name the site. Describe the stop.
Use the option sheet to include Website actions in a setup request. A public website name and a short account of the desired review state are enough to start. Keep private links and credentials out.