I am very new to sales-force, In sales-force the owner can manually share the account with another user. I need a list that shows the manual sharing of all accounts.Would it be possible by using apex class or trigger or any other way?
Examine the AccountShare table, especially something like that:
SELECT Id, AccountAccessLevel, AccountId, UserOrGroupId
FROM AccountShare
WHERE RowCause IN ('Manual', 'TerritoryManual')
LIMIT 100
You can read up more about the values here, there's also a nice example of Apex used to share records based on rules that can't be expressed in normal sharing rules.
UserOrGroupId is tricky one -> if it will start with "005" that's an userid and your search is done. Otherwise you'll have to look it up in Group table. This will contain real groups (called "Public Groups" in the setup) as well as system-generated groups that correspond to Queues, Roles, Roles+Subordinates, Territories etc. So you might have a bit of recursive world of pain here trying to learn who actually is in this group.
I admit I was lucky in the past, level of nesting I saw in the Group table was never > 2 levels deep.
Related
I'm an intern student at a company that does both wiring and aircon services. The job that they gave me was to make a database for them. I don't have any experience in anything related to databases.
So, I started to look up videos and stuff to at least learn a bit about databases and made something that works and I made it after 1.5 months of learning.
in the database that I created,
I have 1 table (CustomerDetailsT):
CustomerID (pk)
CustomerName
PhoneNumber
Address
Aircond (type and model of ac,ex: WM daikin 1.0HP)
AcDetails (what has been done for the ac.)
Others (yes/no) (Wiring, installing a fan and so on)
WhatHasBeenDone (shows what has been done for others)
Then 3 queries (CustomerOthersDetailsQ, CustomerAcDetailsQ, CustomerDetailsQ).CustomerAcDetailsQ has CustomerName, PhoneNumber, Address, Aircond and AcDetails. CustomerOthersDetailsQ has CustomerName, PhoneNumber, Address, Others, and WhatHasBeenDone.CustomerDetailsQ has CustomerID, CustomerName, PhoneNumber and Address
And 1 form with 3 subforms.
it's a search form, which would search for customers as we're typing in their name/phone number and it will show what has been done for the customer.
With this, I have created what the company wants, but now they want to add dates. Dates which would show when we have done something for a customer. Dates for Aircond and the Others stuff.
I've tried with what I know and it didn't work. tried searching it on youtube and google, but still couldn't find it.
how can I go about doing this?. I have tried having separate tables for each service, but it became a hassle when I wanted to create a new customer. . I hope I could some help, I could send pictures if someone needs them.
[1]: https://i.stack.imgur.com/mtrmC.png [The Customer search form] [1]: https://i.stack.imgur.com/A3Y9d.png [example of a customer that has ac installation] [1]: https://i.stack.imgur.com/dsGL5.png [example of a customer that has both ac and wiring done]
Acknowledging the question is too broad, here is some guidance. One of the nice things about Access is that each database is a single file. First protect your work by finding that file and make two copies. Make a backup and a play around version. Only mess with the play around version.
Your question indicates you are still learning Table Normalization and 1 to many relationships. Both of these topics are general to all databases, so you don't have to restrict yourself to just Access when looking for guides and Youtube videos.
Part of normalization is putting separate entities into their own tables. Also, in Access there is a big payoff for using the Relationship Tool, so here is a rather lame example of normalization:
Make sure to select the checkboxes when setting up relationships.
WhatHasbeenDone should also have WhatHasbeenDoneDate. I've wrapped AC and Other as Unit because later it will be easier than having two WhatHasBeenDone tables(AC)(Other).
Now imagine someone taking the customer request call. They just want to see a form to enter the customer details, request, unit-type, etc. They don't want to see those tables. Even with training entering data in the tables is error prone. The person fulfilling the request just wants to enter what they did and when. That's how you start to figure out what your final Data entry forms will look like.
Since we normalized the tables and used the relationships tool, the payoff is Access can give us an assortment of working starter forms. Select Each Table and then hit Create and then hit Form. Choose your Favorites and start playing around from there. While playing, keep in mind that Access will not let you add an item on the many side of a relationship unless there is an item on the 1 side.
For example I selected the customers table and hit create form:
Access uses a concept of form and subform based on separate but related tables. So, to get a form that shows what has been done for each customer I created a form for the What has been done table, and dragged it onto the customers form:
Unless an ID is also being used as a part number or something there is probably no reason for the person entering data to see it. So I removed the texboxes bound to ID's. Except for UnitTypeID, where I replaced the textbox with a combobox that displays the userfriendly UnitDescription. The ID's are still part of the form recordsources, Access is still adding new IDs and using those IDs to put the appropriate data in the right tables.
Oh, didn't we need dates (went back and added a date to the table, and adjusted the subform accordingly). Also changed the subform format from single record to continuous records to show multiple dates:
In conclusion and in my opinion your final forms will use VBA behind the scenes to insert data from the forms into the tables. This is because either you will want to rapidly insert multiple records or How the end users think about the data will not match the default forms and subforms approach Access depends upon to figure out how to insert the data. However, the default approach is fast and I always use it for version 1 of my Access Databases.
P.S. For simplicity I avoided including any Many to Many relationships
For a project, I have a database with some tables.
All of them are related between them. The table organization has a relationship with offer and user, etc.
However, I have some columns that only serve to link two tables together.
Take a look at the diagram. I use users_interests to link the user to his interests. Same thing for badges and group.
It doesn't really feel efficient. When I try to get the interests of a users, I must first go through requesting the user interests and from that, require the interest details.
Is there a way that I can request the interests of an user without having to go through a second table ?
https://dbdiagram.io/d/5da3f119ff5115114db53551
There's a couple things you should consider when looking at this question/functionality and what you're going to be doing with the data.
Do you have a unique set of interests that will remain the same or be added to, without duplicates?
Do you need to have multiple interests for a single user?
If you answered "yes" to both of these questions, then you should leave things the way they are. You'll be able to reuse the same interests entry for multiple users as well as each user being able to have multiple interests.
If you only want one interest per user, but want to keep a "master list" (aka: lookup table) of interests, then you can move the interest_id to the users table.
If you don't care about duplicates, but you still want each user to have multiple interests, move the name column to the users_interests table.
Finally, if you don't care about duplicates and you want each user to have a single interest, move the name column to the users table.
FYI, how you currently have the tables structured will likely take up less disk space for a large amount of users.
It's unclear what you're trying to do, so I included all options. Each option has it's own set of pros and cons, and each will be required of some other project or another at some point. You might want to learn the difference and reasoning behind why you would use one option over another now, so you don't have to think too hard about it later.
You can do it if you will make interests like this
id
user_id
name
but then you will lose uniqness of your interests, you will have many rows with the same name only because they connect to different users. Now db is perfectly ok according my understanding...It is as it should be
I am designing a database for a sales company having a complex workflow. The flow starts at Sales Officer, then go to Team Lead and finally Manager. Before approving a proposal, manager will send it to the Division Business Analyst. After getting remarks from dba, he may send the proposal back to sales officer for modification in the proposal. The manager may also reject the proposal. If satisfied, manager will forward it to Director, Sales. The tables designed so far as follows:-
Table: ProposalBasicData
Id, Title, ProposalDate, Scope, Objective
Table: ProposalState
Id, Name
(Values - Forwarded , Approved , Returned , Rejected)
Table: UserType
Id, Name
(Values - SalesOfficer, TeamLead, Manager , DBA, DirectorSales)
Table: WorkFlow
Id, StartUserType, NextUserType, StateId, IsActive
Table: RequestAction
Id, ProposalId, WorkFlowId, UserId, ActionDate
Please suggest regarding the design.
There are many questions raised by such problems. Ex:
in your tables, Workflow defines transitions from state to state as changing the assignment from one user to the next.
this can be an issue. Lets say the user is sick, leaving, on vacation, ... Then your flow is blocked.
It does not allow for the group concept either.
others (like I) would define a transitions table. StartState, NextState.
The workflow would be a list of transitions.
Each transition requires the user to be of a certain type. Or from a user management point of view, have a certain role, or be member of a group.
If your workflow is fixed and is not subject to change, your method could be ok. But if the workflow is flexible or might be changed / adapted, you should go with something more flexible.
The type of setup you are talking about make me think of the Jira software (form Atlassian), where you define tickets, with status, workflows and users. Is it possible for you to use (i.e purchasse or OpenSource) a workflow management tool? It might be cheaper in the long run than building one.
Your model will potentially be expanded to include:
clients. Which client is the proposal for?
who is the sales representative or account manager who is responsible for auditing the workflow and moving it forward?
link to other systems: how does it link to purchasing, accounts receivable, ...
All this to day, this requires an in-depth analysis which is hard to do on a medium such as this (SO).
EDIT: 20181004
I added the following model following your comment. I decided to put the workflow(s) in the database:
Notes (tables in alphabetical order):
Employee
Each employee can be linked to n number of EmployeeRole via the Employee_has_EmployeeRole table.
Proposal
An Employee is linked as the Sales Officer, since he initiates a proposal.
A workflow is linked since many workflows could exist for different proposals.
Transition
Linked to State twice. The start state and the end state.
An EmployeeRole is linked, to identify which role an employee must have to perform this transition.
Enforcing that will be done by the application.
Workrlow_has_Transition
Links Transitions to Workflows.
The Employee who completed the transition is recorded here.
The date it was done is also kept here.
The OrderInWorkflow is just a number that allows you to order Workflow_has_Transition entries.
The application will have to make sure a Transition is not done before the others of lower order are done (i.e. DoneDate is null).
It will also validate that the Employee trying to complete it has the proper EmployeeRole.
Now, the employee group concept. You can say that a group are employees with the same EmployeeRole. Therefore, when a notification needs to be sent by your application, send it to all users with the required role for the Transition. This avoids you having to create an EmployeeGroup table, which links employees together.
Application scenarios:
- Start a Proposal
- Verify that the user trying to start a new one has the role "Sales Officer"
- Collect basic information.
- Link the Sales Officer to it (current user).
- Link a Workflow to it. Only propose the workflows which have at least 1 Workflow_has_Transition.
- Send a notification to the Employee(s) which have the EmployeeRole for the first Workflow_has_Transition for this new Workflow.
- These employees receive a notification.
- Progressing through the workflow
- An employee receives a notification about a Proposal and it's "todo" Transition.
- Employee views Proposal and Workflow (use the OrderInWorkflow to ORDER BY Transitions).
- Employee approves if he has the proper EmployeeRole, fill DoneBy_idEmployee and DoneDate.
While going through your application scenarios, you will find gaps or missing items.
Ex.1 do you want to record the rejection of a Transition? How would that be handled then? You send a notification to the employees with the role for that Transition to review it?
Ex.2 do you want to keep the complete history of the proposal? Ex. it Transition X is rejected twice, but approved the third time around.
There are many scenarios like this which will show the weaknesses of your model, which you fix as you complete this analysis. Now it is not perfect, I did not put a lot of time on it. But it is a starting point and illustrates my idea.
I would suggest you structure some where along this
ProposalBasicData {PBID,Title, ProposalDate,Scope,Objective}
ProposalState {PSID,Name}
UserType {UTID,Name}
User {UID,Name,UTID(Usertype UTID FK) }
Request{ RID, StartUID, StartDate ,PSID, IsActive }
RequestAction {AID,RID, RequesterUID, ReceiverUID, Date, Comments, IsCompleted }
as I think there could be multiple users of the same type, more over you would want to have comments on why it a RequestAction was rejected, A requester would make a requestAction to a receiver and if its completed it would show in the system make life easier when handling multiple requestActions of the same Request.
Hope this helps but i suggest you make a flow chart and look at what are all the possible use cases.
In a financial analysis program there is an account object, and a loan account object that extend it. The loan object only has couple more attribute than the account. Which one of the following will be the recommend DB design ?
Table for the account, and another table for the extra loan
attribute with 1 to 1 relationship.
Two separate tables.
One table that has all fields, and ignore the loan attribute for
basic account.
You should go for first approach.
For relationship cardinality, you should consider what data will be stored in each of the object. Are you going to maintain history for it.
As per my understanding about the above said objects, you should go for one-to-many relationship.
You're talking about implementing polymorphism, which while not possible in a relational database is a good way to assess the pros and cons. Option 1 is similar to subclassing, where the loan account inherits everything from the account and extends it. So use that if you want the account to be a superclass...in other words if you add a new kind of account, say credit card, you will add another table for it and have it relate to account also. That means the account table must remain generic...account number, balance, etc.
Option 2 is treating the two types of accounts like separate classes. Use that if they won't share many CRUD operations, because now a simple balance update in response to a transaction has to have different code somewhere.
Option 3 is the generalist approach. It's big advantage is simplicity in modeling and querying. It's big disadvantage is that you won't be able to implement NOT NULL constraints on columns that need to be there for some account types but not others.
There's a 4th option to combine the first 2 options which provides a solution similar to the party abstraction for people and organizations. You have 3 tables: 1) an account table that handles the basic elements of account id, balance, owner, etc.; 2) a loan account table that has the additional columns and a reference to account id; and 3) a basic account table that just has a reference to account id. This may seem like overkill, but it sets up a system that you can extend without modification. I've used the pattern many times.
If you had to design a database with paid users and trial users would you put them in the same table and differentiate between them with a field? Or would you put them in two separate tables?
Or would you do the best of both worlds and put them in the same table but create two views 1) PaidUsers and 2) TrialUsers
Thanks!
I just express some performance considerations in following opinions.
In single user query(ex. login check, or data retrieving for single user), there are not significant differences between these two strategies.
But if you need some statistic data, for example, one for paid users and another for trial users. And seperating to two tables may be a good idea.
Otherwise, if you need some statistic data whatever paid users or trial users, single table may be a good idea.
What if you need both of scenarios? Well, I think that would be a case which some common attributes exist between two kinds of users.
These common attributes should be put in one table, and dedicated attributes for particular users should be put in 'sub-table' inheriting from former table. Just as vonPetrushev said.
Since your paid users would probably be related to some additional data, but still have the same fieldset as non-paid, the correct way to do this is [is-a] approach:
User
id
username
password
fullname
...
Paiduser
user_id [fk->User::id]
account_id
.... [other addidional data]
EDIT: Now, the trial users will be all records in User that does not have entry in Paiduser. I'm assuming that Paiduser fieldset is a superset of the fieldset of a trial/normal user [User].
EDIT 2: To get a list of trial users, which are 'set difference' between User and Paiduser, the following sql should work:
select u.*
from (User as u
join Paiduser as p on u.id<>p.user_id)
The best solution may depend on database type. My experience is with MySQL and SQL Server. I've always put all users into a single table. Then differentiate as needed using fields. This could apply to paid/ unpaid or anything else. This solution meets 3NF standards and seems easier to me for maintenance etc. What reason would there be to use multiple tables?